aria thoughts

>From Mark, Kelly, Henny, and Jim

0. I 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.

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

	--- yes! Informational vs non-informational. 

	--- I 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?

	--- Many cell phones do now have AT and I hope that this will only
improve and get 	more widespread. I personally 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. Isn't this an 	authoring issue? I assume 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 my 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.  My concern is that
what may work well on 	constrained devices/bandwidths currently will stop
working if developers decide to I	mplement accessibility using ARIA.

	--- Excellent point. It should be brought up. Again, is this not an
authoring issue. 	If they can do incorrect things they will. If they
don't write mobile versions and 	sniff for UA/platform, what can be
done? 
	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/ 

	--- I'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.  I 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).  

	--- I'm 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?

	I 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 specificed rules that help me understand the precise
way to implement 	this in a UA for all element types, nested or not?
If 

C.  I 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>

	I 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.  I'm 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.

	--- that will be a lot of javascript writing for the authors. Are
you saying ARIA 	should propose that? This section is informative, so
is not something that is part of 	conformance.

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, am I 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.

Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 16 April 2009 17:05:16 UTC