[WG: Accessibility] Addressing old and 2.7 accessibility bugs.

[Michael S Elledge]

This is awesome, Gonzalo! Thank you for doing this!

Mike

Silverio, Gonzalo wrote:
> Hi,
>
> I have gone through all the issues that list "Accessibility" as a component
> with the aim to draw some common threads that may point to common best
> practice solutions, for which I am depending heavily on community experts
> for feedback. 
>
> All the critical bugs are either FCKEditor related of deal with <select />
> elements that trigger a form submission on change. I think the later is
> addressable (see below). The FCKEditor issue needs to be addressed on its
> own, I think, as it is rather complex, has dependencies and offers a range
> of possible solutions that need to be puzzled and thought out carefully.
>
> The rest of the issues can be grouped as below. The goal here is to clear
> all the outstanding accessibility issues, as well as any that are reported
> for 2.7. As a solution is accepted it either gets applied to the specific
> locale or a patch gets created so that the original tool owner can hopefully
> just apply it without problems.
>
> What follows describes the common issues with references to example JIRAS,
> proposes solutions and asks questions revealing my vast ignorance.
>
> Thanks!
>
>     - Gonzalo
>
>
>
>
> COMMON THREAD ISSUES
>
> --------------------
> 1. <select /> onchange
> --------------------
>
> A <select /> is used for navigation with an onchage handler that triggers a
> form submit [IE 6 and 7]. Keyboard  selection of options becomes impossible.
>
> Example:
> http://jira.sakaiproject.org/browse/SAK-12820
>
> Proposed solution:
>
> Put a screen-reader-only instruction in front of the <select />.  Something
> like
>
> Label (Use ALT + arrow keys to select a choice. Then hit Enter)
>
> The parenthesis text would be renderered offscreen. We did this a while a go
> with the More sites tab.
>
> Question 1: It is requesting a change in the user's behaviour, so may not be
> fair. Is it?
>
> Question 2: This was reported against JAWS (a fairly older version) - is it
> also the case in newer JAWS and other AT? Will the suggested fix apply to
> all?
>
> --------------------
> 2. Click reveals extra information.
> --------------------
>
> Example:
> http://jira.sakaiproject.org/browse/SAK-11679
> http://jira.sakaiproject.org/browse/SAK-12822
>
> Proposed solution: trigger change with keyboard, add role and aria
> attributes to dialog container (role="region" aria-live="polite"
> aria-atomic="true" aria-relevant="additions removals") so that AT user is
> notified of changes. What aria-live value would be generically the best?
> Mybe there is no generic value and it all depends?
>
> --------------------
> 3. Missing form field labels
> --------------------
>
> http://jira.sakaiproject.org/browse/SAK-16597
>
> Proposed solution: supply <label /> where needed. Where the <label /> would
> crowd things visually, render off screen. An example may be any of the
> permission checkbox grids.
>
> Question 1: is a <label /> really needed for an input in a grid when the
> table is well constructed? Would it just be overkill?
> See:http://jira.sakaiproject.org/browse/SAK-11203
>
> Question 2: in some very few specific contexts a label with a *for*
> attribute matching the *id* of a labeled item will be fairly hard to
> implement. Options? Sadly the same constraints will not allow an ARIA
> "labelledby" and label relationship.
>
> --------------------
> 4. Links with same text
> --------------------
>
> Some cases are just mistakes in initial design. Others are there because the
> difference between link A and link B is a function of a set of *visual* cues
> (proximity to other elements for example, position in a list, etc.). See
> populated Announcements list as a site maintainer - the link that is the
> same is "Edit". 
>
> Another example would be http://jira.sakaiproject.org/browse/SAK-11421
>
> Question 1: Is there a heuristic for when the links need to be
> differentiated?
>
> Question 2: Is there a preferred method for differentiating link A from link
> B when the link text (or image + alt) needs to remain *visually* the same?
> Something like using title attributes so that:
>
> Edit [title="Edit Announcement -The first announcement]
> Edit [title="Edit Announcement -The second announcement]
> Edit [title="Edit Announcement -The third announcement]
>
> Some other way?
>
> --------------------
> 5. Complex scripted interactions
> --------------------
>
> Visual cues and focus management problems. A user action results in a
> *visual* change in the screen. A visual user can take the next required step
> because she sees it. How to help AT users realize what the next step is?
> Live regions, focus management?
>
> Example: create a site, select "course" - a control appears allowing user to
> select a term. Or - in a site with groups, create an announcement and select
> "Displays this announcement to selected groups only." list  control appears
> so that user can select groups.
>
> Proposed solution: open.
>
> --------------------
> 6. Instructions specify visual cues.
> --------------------
>
> But *visual* cues are of no help to the AT user.
>
> Example:
> http://jira.sakaiproject.org/browse/SAK-11201
>
> Proposed solution. When *visual* cue and cue as an AT user would experience
> it differ, add AT-only text clarifying this. For example:
>
> >From SAK-11201: "when attempting to add or remove files in "resources," the
> directions refer to an "x" button. The screen reader does not indicate this
> button but instead reads out, "remove file," etc as links."
>
> Screen would specify "If you change your mind about uploading one of your
> files, click the 'X' button beside it[AT-only text: (link labeled - remove
> file)]. 
>
> --------------------
> 7. Complex asynchronous interactions.
> --------------------
>
> See:
> http://jira.sakaiproject.org/browse/SAK-11670
>
> In this Tool Order helper case there is a complex interaction:
>  - reordering tools - this is managed via the FLUID reorderer, so done
>  - changing tools (edit tool name, hide, delete)
>  
> This particular bug relates to the tool edit (click on link - text field
> appears, edit the field and either accept or cancel changes, which are then
> submitted in the background asynchronically). I think focus management and
> good labeling will address the issue, but need to work with some experienced
> AT users in testing.
>
> --------------------
> 7.Table summaries
> --------------------
>
> Not provided - or insufficient.
>
> Proposed solution: provide them.
>
> Question 1: What is a good summary? Some summaries are pretty verbose: see
> Resources list, for example. Others are very telegraphic. What is the happy
> medium that will help without getting in the way?
>
> Question 2: some tools will render tables for layout, the end (JSF). What is
> the best way to flag that this is not a tabular data table (ARIA
> role="presentation")?  Is this even needed?
>
> CONFUSING BUGS
>
> --------------------
> Missing focus
> --------------------
>
> Bug reports that focus should be directed to a specific place after a user
> action. But user action was a POST, so naturally focus will go to the top of
> the [new] page.
>
> Examples: 
>
> http://jira.sakaiproject.org/browse/SAK-11671
> http://jira.sakaiproject.org/browse/SAK-8233
> http://jira.sakaiproject.org/browse/SAK-11661
>
> Or maybe this is label confusion? The tester assumed that the action would
> keep her in the same context, in which case maybe the label is incorrect. In
> the case of SAK-8233 maybe the button should not say "Cancel" but "Return to
> Site Info"?
>
> I guess I could use guidance here - all of these are POSTS that load pages.
>
> --------------------
> ALT or TITLE?
> --------------------
>
> See:
> http://jira.sakaiproject.org/browse/SAK-11672
>
> What is the prefered method to convey the meaning of an image inside a link?
>
> --------------------
> Accesskeys?
> --------------------
> Where supplied - how are they to be made discoverable? In portal now this is
> announced to AT users, in tools it is not. An optional link to an
> accessibility help document supplied the mapping. But is there a way to add
> this helper info directly in tool? Something like adding it to the title of
> the input?
>
>
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>