Feedback on ARIA Spec and Best Practices Guide

All-

Attached is my feedback on both the WAI-ARIA Specification, Last Call  
Working Draft and the WAI-ARIA Best Practices Guide.
I hope that it is not too late to submit my feedback.  Let me know if  
you have any questions.  I'd be happy to help out further in any way  
that I can.

Thanks,
Todd


General Thoughts
================

My overall concerns with the current state of the ARIA Best Practices 
document is that it contains a lot of examples and recommended solutions that 
are actually not considered industry best practices for web development and 
web accessibility.  Consider the toolbar example that is presented in the 
section titled "General Steps for Building an Accessible Widget with ARIA".  
This example has the following problems:

1.	Poor Use of Semantic Markup

	Using the <img> element as the basis for a button control is not a good 
	use of semantic markup and contradicts the use case for ARIA outlined in 
	section 1.2 of the ARIA Specification itself: "ARIA is intended to be used 
	as a supplement for native language semantics, not a replacement."
	
	Why doesn't this example use <input> or <button> elements as the basis for 
	the toolbar's buttons?  If it did it would better illustrate how ARIA 
	can be used to supplement for native language semantics.  It would also 
	make for a toolbar that is more accessible in older browsers 
	(e.g. IE 6 & 7) that don't support ARIA.  This is especially important 
	considering right now the browsers that don't support ARIA outnumber 
	those that do.
	
2.	Use of inline JavaScript event handlers

	This has long been considered to be a bad practice, and I was surprised to 
	see this technique appear so often in the ARIA Best Practices Document.

3.	ARIA roles and tabIndex are applied inline rather than being managed 
	via JavaScript

	Since ARIA-enabled widgets *require* JavaScript for keyboard support and 
	state management, I think that it only makes sense that ARIA roles, states, 
	and properties for widgets should only be applied using script.  The same
	goes for the tabIndex attribute.  I'd like to see this mentioned in the 
	ARIA Best Practices document and applied to the examples.


I think that the examples in the ARIA Best Practices document should 
represent us putting our best foot forward--showcasing a culmination of 
best practices for accessibility made even better with the introduction of ARIA.  
Instead the document leads with example that represents a bunch of really bad 
practices.  But I don't want to criticize and offer no solutions, so if you are 
looking for developers to volunteer examples the ARIA Best Practices Document I 
would be happy to volunteer.
	

Feedback on Specific Sections
=============================

From the section titled "General Steps for Building an Accessible Widget 
with ARIA": 

-	Point 2: "From the role, get the list of supported states and properties": 

	-	There's a sentence in this section that is slightly misleading.  It 
		reads: "By setting tabindex="-1" on the toolbar, we have specified that 
		the toolbar will receive focus in the document order"  This could be 
		confusing to developers since setting the "tabIndex" attribute to -1 
		removes an element from the browser's default tab flow.

-	Point 7: "Synchronize the visual UI with accessibility states and properties 
	for supporting user agents"

	-	I like the mentioning of IE 6's lack of attribute selector support.  I 
		don't like the time spent suggesting fixes to IE 7's broken attribute 
		selector support.  I think that this section would be more useful if it 
		simply made it known that currently not all of the major browsers have 
		support for CSS attribute selectors, and provided an example of how to 
		engineer a solution for styling state that worked consistently well 
		across all browsers.  In this case that means avoiding use of attribute 
		selectors for styling updates to a widget's state, and instead, applying
		class names that represent, and can be used to style state.

-	Point 11: "Review widget to ensure that you have not hard coded sizes"

	-	I like how this section tells the user to avoid "px" as the unit for 
		defining font sizes.  I don't like the suggestion of using the "em" unit
		to replace "px" as we've (Yahoo!) found "em" doesn't scale as nicely in 
		IE 6 and 7.  We've done a lot of research on fonts at Yahoo! and believe 
		that using percentages scales the most consistently cross browser.  Our
	 	best thinking on this can be found here:
	
		http://developer.yahoo.com/yui/fonts/
	

From Section 3.2.1 "Using Tabindex to Manage Focus among Widgets"

+	Item 1: "Use onfocus to track the current focus"

	-	I think that when it comes to listening to focus in the browser, the 
		ARIA Best Practices document should reference PPK's focus delegation 
		technique:

		http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html

		We've rolled this technique into YUI and it has been both incredibly 
		useful and helped us improve the performance of our widgets.  Read the 
		following blog entry for more info:
		http://yuiblog.com/blog/2008/10/07/onfocus-onblur/
		
+	Item 2: "Refresh an elements style using onfocus()"

	-	I would consider removing this item since it is mostly repeating points
		that are mentioned in item 8 titled "Always draw the focus for 
		tabindex="-1" items and elements that receive focus programmatically"

+	Item 5: "Dynamically change focusability using the tabIndex property"

	-	I would go so far as to recommend always updating the "tabIndex"
		property to 0 (or greater) before focusing an element.  This provides 
		two benefits:

		1)	You completely avoid the problem in IE where the default browser
 			focus outline isn't drawn when an element is focused 
			programmatically.  This ensures the browser's default rendering of 
			focus, which is beneficial considering that it is already familiar 
			to the user.

		2)	If the currently focused descendant of a UI control has a tabIndex 
			of 0 it allows the user to press shift+tab to move back 
			to where they were if they exit a control and want to go back.
			
+	Item 6: "Use setTimeout with element.focus() to set focus"

	-	Is use of "setTimeout" really necessary?  If so, can you more accurately 
		describe the problem?  The current description of the problem seems 
		really vague: "The timeout is necessary in both IE and Firefox 1.5, to 
		prevent scripts from doing strange unexpected things as the user clicks 
		on buttons and other controls."

	-	I would avoid mentioning Firefox 1.5 since it doesn't have enough 
		market share at this point to be of enough significance.  And it makes 
		the advice seemed dated.

	-	If use of "setTimeout" fixes larger usability problems in IE, then call
		those out as I think it will give this solution more credibility.

+	Item 7: "Don't use :focus or attribute selectors to style the focus"

	-	This is an important piece of advice, considering IE's limited support
		of the :focus pseudo class and lack of attributor selector support in 
		IE 6.  That said, the suggested example solution of styling focus via 
		an inline style is a bad one.  I'd like to see the recommended solution 
		be: Style focus by using a "focus" event handler to apply a class to the
	 	focused element.  That way you can centrally manage how focus is styled.

+ For item 8: "Always draw the focus tabIndex='-1'"

	-	I would remove this item as it seems to suggest a solution to a 
	 	problem that, as I suggest above, can be avoided entirely if developers 
		simply update the tabIndex property to 0 before programatically 
		focusing an element.  
	
	-	I would replace this item/section with a new one that focuses on the 
		importance of developers providing a clear, consistent rendering of 
		focus through:
		
		1)	Relying on the browser's default rendering of focus--something the
			user is already familiar with.
	
		2)	If developers are going to customize how focus is rendered, it is 
			important that focus is rendered consistently across all focusable
			elements within the scope of the site/application so that the user 
			only has to learn one focus model.
		
+	Item 9: "Prevent used key events from performing browser functions"

	-	Update example so that it doesn't use an inline event handler

	-	For Opera 9 and Firefox 2: calling the "preventDefault" method in 
		response to the "keydown" won't prevent undesired scrolling.  To fix the
		problem in Opera 9 and Firefox 2, you also need to call 
		"preventDefault" in response to the "keypress" event.

+	Item 10: "Use key event handlers to enable activation of the element"

	-	If you are interested in providing more detail on this point, this 
		technique is necessary in IE, Firefox and Webkit when you use the 
		"tabIndex" attribute to make an element that is not natively 
		focusable, focusable.

	-	Opera is the only browser that fires the "click" event when the user 
		presses enter while focused on an element that was made focusable via 
		the use of the "tabIndex" property.
		
		
Section 3.2.6.1. "Steps for Defining a Logical Navigational Structure" 

	Point 4: "Assign landmark roles to each region"
	
	-	I think that the following needs a better explanation: "Skip to main 
		content links impact the layout of applications and only address one 
		main content area."  How does a skip navigation link negatively 
		impact the layout of a page, especially if it is hidden offscreen 
		using CSS?

	Point 6: "For landmarks unsuited to specialized region ARIA roles"
	
	-	Why doesn't the example show use of the generic "region" role, as 
		mentioned in the preceding paragraph?

	
Section 3.2.6.2. "Structural Roles that Facilitate Navigation with 
	Assistive Technologies"

	Point 1: "After you have divided your Web page into regions through the use 
	of role landmarks and custom regions, you must make a decision: Is your Web 
	page an application or not?"

	-	This seems like an unnecessary designation to force developers to make
	 	as the web is full of examples of pages that are hybrids between 
		documents and applications.  The Yahoo! homepage and Facebook are 
		two good examples of pages that don't fit perfectly into the designation
		of application or document.
	

	Point 2: "Dialogs and alert dialogs - special case application roles 
	WAI-ARIA provides dialog and alertdialog roles that are to be treated as 
	special case application roles. Like application, screen readers will leave 
	the main job of keyboard navigation up the application"
	
	-	I think all ARIA-enabled widgets should work like this.  The screen 
		reader should be able to keep the virtual buffer on by default, and 
		should toggle it off on the fly if the user focuses into a widget.


Section 3.2.6.3.1 "Header Levels Versus Nesting Levels"

 -	Can we just omit or deprecate any ARIA roles (such as heading) that 
	directly duplicate elements already available in HTML?  
	
	
Section 3.2.6.4.2 "Groups and Their Applicability"	

-	I love the idea of groups, and I think that the concept should be applicable
 	as a means of semantically organizing any of a widget's descendants.  If 
	this were the case, it would eliminate the need for the "separator" role 
	and help simplify the spec.
	
Section 3.2.6.5.2 "Marking Descriptive Sections"

-	I don't understand the use case for the example.  Why wouldn't you just 
   	use alt text?

Section 4.1.2 "Describing"

-	This section contains a really horrible example:

	<a role="button" aria-describedby="winClose" href="#" onclick="fakewin.close()">X</a> 
	
	Why would anyone ever code a button like this?  I would be up for helping 
	to provide better examples of using aria-describedby.
	
The "activedescendant" attribute

-	I don't understand the need for this attribute and think that it should be 
	deprecated.  Use of the "Roving TabIndex Technique" as a means of 
	managing a widget's active descendant is a much better backward and forward
	compatible solution.  I wrote up a blog entry on this topic back in Feb., 
	you can find my arguments against the "activedescendant" attribute here:
	
	http://yuiblog.com/blog/2009/02/23/managing-focus/


Section 4.3 Categorization of Roles

-	Currently there is a typo in the list that introduces the six categories.  
	The item labeled "Specialize Regions" should be "Application Structure"
	
-	I think that the current categorization of ARIA roles could be further
 	simplified, and as a result, improved.  My suggestions are to:

	1.	Kill the "Application Structure" category and combine what is currently 
		"User Input Widgets," "User Interface Elements," and 
		"Application Structure" into a single category called "Widgets".
		
	2.	Pull the "application" role from the "Landmark Roles" category and 
		create a new category called "Specialized Regions" that includes just
		the roles of "document" and "application"--since these two roles are 
		truly "special" in that the set/control the overall context the user 
		is working in.  They're also "special" in that they can be used to 
		control weather or not a screen reader's virtual buffer is toggled 
		on or off.
	
	This would leave five categories of ARIA roles:

		1.	Base Types
		2.	Widgets
		3.	Document Structure
		4.	Landmark Roles
		5.	Specialized Regions

-	There are a handful of ARIA roles that I believe should be either removed 
	or deprecated, as they duplicate rather than supplement native language 
	semantics.  The roles I would remove or deprecate are:
	
	-	img
	-	separator
	-	heading
	-	link
	-	list
	-	listitem

	**	The removal of these roles is important considering that their presence 
		seems to contradict the intend use of ARIA as mentioned in section 
		1.2 of the specification titled "Use Cases" which says: "ARIA is 
		intended to be used as a supplement for native language semantics, 
		not a replacement"
		
-	With all of the above changes in place, this is how I would see the 
	breakout of the individual roles:

	-	Base Types (unchanged)

	-	Widgets

		-	checkbox
		-	combobox
		-	input (abstract role)
		-	listbox
		-	option
		-	radio
		-	radiogroup
		-	range (abstract role)
		-	select (abstract role)
		-	slider
		-	spinbutton
		-	textbox
		-	button
		-	menu
		-	menubar
		-	menuitem
		-	menuitemcheckbox
		-	menuitemradio
		-	tablist
		-	tabpanel
		-	tab
		-	toolbar
		-	tooltip
		-	tree
		-	treegrid
		-	treeitem
		-	alert
		-	alertdialog
		-	dialog
		-	log
		-	marquee
		-	progressbar
		-	status
		-	timer


	-	Document Structure

		-	article
		-	columnheader
		-	definition
		-	directory
		-	grid
		-	gridcell
		-	group
		-	math
		-	note
		-	presentation
		-	region
		-	row
		-	rowheader
		-	section (abstract role)
		-	sectionhead (abstract role)


	-	Landmark Roles

		-	banner
		-	complementary
		-	contentinfo
		-	main
		-	navigation
		-	search


	- Specialized Regions
	
		-	application
		-	document