User Agent Accessibility Guidelines Working Group Comments on ARIA Last Call

PF:

Below are comments of the User Agent Accessibility Guidelines Working Group on ARIA last call documents.

0. We believe that role=presentation is problematic, beginning with the word "presentation", continuing on to possible misinterpretation of what should be presentation, and possible mis-use of role=presentation by authors who want to avoid extra effort, thereby hiding real information from AT who respect that role.

We understand where "presentation" comes from historically, and do have some mixed feeling about raising this as an issue, but we believe the role for images (and other elements) that are presentation, more correctly boils down to role=informational and role=noninformational (or decorative) elements.

We think the examples flagged are a good discussion point for abuses, well intentioned or otherwise, of role=presentation. This needs more clarification/examples       as developers are going to get confused from the outset and we'll be stuck with bad implementations from the outset.

In case you've not seen it there was a discussion on the Free
ARIA list just a few    days ago on screen reader support for
role=presentation and what it means
http://groups.google.com/group/free-aria/browse_thread/thread/73a6b0d33c1402
73. So  role=presentation is descriptive of presentational elements (such as tables, spacers    etc) but not the content in these. As such links or
text in a table are parsed but not      TH, TD etc or alt text (*if* I have
followed the conversation correctly). For me the        choice of the word
"presentation" is confusing because we are all working from the notion that either an element is completely accessible or completely not.

A.      Assume I am a user of mobile device browser in Ghana.  The
connection is slow and I        turn off images in the mobile browser to
improve rendering speed.  Note: a mobile        device browser being thin MAY not support aria. Also, why bother with ARIA if there is  no AT on the
platform?

We do understand that many cell phones do now have AT and we hope that this will only
improve and get         more widespread. Some in UAAG can see a use case for
people who are not disabled to  use AT on cell phones as the context is so
disabling in itself. Is this just an authoring issue that the UA will ignore/repair that which it does not      understand.

With AT on the platform, if ARIA was supported on mobile, wouldn't one benefit be       to help all users with tabbing within widgets and so on?

What should be displayed if the valid code below is presented on a mobile browser that doesn't support ARIA and has image rendering off?

    <p>
      You can <span id="a1">update</span> your personal data or
      <span id="a2">delete</span> it using the following buttons.
    </p>
    <div class="coolbutton" role="button">
      <a href="blah-update-info.php"><img src="update.png" alt=""
      labeled-by="a1"></a>
    </div>
    <div class="coolbutton" role="button">
      <a href="blah-delete-info.php"><img src="delete.png" alt=""
      labeled-by="a2"></a>
    </div>

If our assumption is right, labeled-by without alt breaks things for
users on less   capable devices (meaning potentially the large and growing
percentage of the global        population who browse the Web on less
sophisticated mobile phones).

Granted, the above example is *stretching* things to make a point,
and should be   covered by Best Practices or Techniques.  Our concern is that
what may work well on   constrained devices/bandwidths currently will stop
working if developers decide to implement accessibility using ARIA.

Frequently if there's the potential to do incorrect coding , it will happen.  If developers do not create mobile versions and sniff for UA/platform, what can be done?  This might also be an item to bring to the requested review of "Relationship between Mobile     Web Best Practices (MWBP) and Web Content
Accessibility Guidelines (WCAG)"
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwb
p-wcag- 20090218/

We'd personally like to see a solution whereby different versions do not have to be     written for mobile as this just fragments the web.

B. Role="presentation" tells the UA/AT that the element (and *some* content) is presentational and not of interest. The UA is not expected to expose "it" to the accessibility API.  We find the text in the ARIA docs overly vague.
For example:

"a table marked presentational results in the table, td, th, tr, etc being removed, while text elements are left."

What happens to caption or summary if present and including text? Are they left?

What about the content in the table that has no other markup other than the     structure provided by the table? Does the UA wrap all content in <div> and add a <br    /> between each cell and <p> for each row?

What about images in the table, which are not text, but contain labeled-by?

This begins to seem like a lot of work on the part of the UA to decide/parse what to include and what not to, especially if coding by authors is haphazard (which we can assume it will be in some cases).

We are also unclear on what MAY or SHOULD (etc) be picked up by the
UA              (http://www.w3.org/TR/wai-aria/#presentation) means. Wouldn't this lead to inconsistent implementations?

We  can envision code that passes validation but is a mess in terms of
what the UA has         to interpret and expose to AT.  What if a misguided author decides, mistakenly that     his data table, authored to look beautiful, is presentational?  What about a data       table that is contained within a layout table marked presentational? What are the rules for nesting of presentation structure?

Has anyone estimated the processing that will have to take place on
the part of both        the UA and AT to properly walk the DOM, apply rules, and extract the information for    the accessibility API?

Being a good UA/AT, what would I do with the following:

        <p>There is nothing to see here. Move along.</p>
        <div role="presentation">
        I lied, there is something here and it is very interesting. <a
href="special.html">For         your eyes only</a>
        </div>

Do I assume that all text within the div marked role=presentation is displayed... or    is only the anchor element content displayed?

What happens if I then put role="presentation" on the anchor element?

Of course, the example is not likely, but you never know how or why it might get used for devious or well-intentioned reasons.

Where are the specified rules that help a developer  understand the precise way to implement    this in a UA for all element types, nested or not?

C.  We know this is an extreme example, but:

<img src="orgchart.png" labelledby="o1">
<div labeledby="o2" id="o1" role="presentation">placeholder</div>
<div id="o2">Organization chart for TPG</div>

We assume the above is valid code.  What is the result?

1.      Section 2.4 step by step

        Step 3 here is titled 3. Preserve semantic structure.  The end of
this makes passing      reference to keyboard access.  Keyboard access
should be broken out as a separate step         and the expectation
strengthened to say something about supporting keyboard navigation expected for the role in use.  Step 6 seems to do this so why then is
keyboard access         in  step 3? This does seem to dangle. The entire last sentence "facilitate keyboard     navigation." would be better in Step 6.

2.      Section 2.5 the tree example
This talks about keyboard behavior for a tree but ignores first letter navigation to tree elements.  This is basic behavior for tree controls on Windows and Mac.  We are not 100% certain on linux but believe it is true there also so should be supported by the author using ARIA and in this example.  We recognize this could be a lot of extra work on the part of the author and raise this is something to be considered for enhanced accessibility.

3.      4.1.4. Base Concept
This sentence is confusing:

However, if the HTML checkbox is modified, the definition of a Checkbox  in this document will not be not affected, because there is no actual  inheritance of type.

4. ARIA-FLOWTO (role) is an interesting concept. It changes the reading order of elements. It also allows the author to provide multiple branches for reading order. If the IDREFs are not meaningful, how will a user know which branch to take. There should be some mechanism (labeledby?) to provide human understandable information about the target. Also, what is the UA supposed to do when the user moves backward in the content? Move to the previous element in the source? Then the user may get confused, because information may be presented in a different order moving forward and backward. Or, is the UA to move to the previous element in the "flow"? In a large document the branching chain could get very complex. Does the UA need an additional 'point of flow' tracking mechanism, or can this be handled in the DOM?

5. ARIA-MULTILINE (role) - Who provides some readable/understandable information to the user indicating the functionality of a 1 character high input box is equivalent to <input type=text> or <textarea>?  Is it the author, the UA, or UA with AT?  This seems to be a repair mechanism to allow authors to use scripting to alter the behavior of <input> or <textarea> to be the opposite of expectations, yet still inform (we hope) the user of the altered functionality. Or, aare we missing something?

6.      6.1.4 Resolving Conflicts with Host Languages - if host language says one thing, and ARIA says something different, then AT SHOULD assign preferences to ARIA feature. What should the UA do? There may be instances where a user is not using AT but still needs access to ARIA information/functions.

Thanks,
UAAG Group Members

Received on Friday, 17 April 2009 16:42:59 UTC