- From: Kelly Ford <kford@windows.microsoft.com>
- Date: Fri, 17 Apr 2009 09:44:08 -0700
- To: "public-pfwg-comments@w3.org" <public-pfwg-comments@w3.org>
- CC: "w3c-wai-ua@w3.org" <w3c-wai-ua@w3.org>
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