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

Mon Feb 1 13:01:34 PST 2010

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?