About alternative name computation as per ARIA specs

During the call on Nov 19, 2013, I suggested that the accessible name computation logic in the ARIA specs is with reference to user interface elements or situations where the role attribute is used to repurpose an HTML element into a UIE. 
More :
The accessible name computation logic within the ARIA specs should be applied to accessible name computation and for this purpose specifically the term is clearly defined:
"The accessible name is the name of a user interface element. Each platform accessibility API provides the accessible name property. The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of the user interface element." [1]

Sure a plain static image too has an accessible name but that is not the subject of the ARIA specs and the above definition clearly excludes it. In other words, the 'Accessible Name Calculation' logic more clearly set out under text alternative computation [2] simply does not apply to static non text content.
 
Secondly, ordinarily it is not necessary to use ARIA to override the native LABEL association for standard HTML form controls. However, one can use aria-labelledby /aria-describedby / aria-label to enhance accessibility in situations like: 
i. Two labels need to be associated with a control
ii. Form is in a table and column and row headers need to be associated with  the controls
iii. Form controls / buttons have identical visual labels but distinct identifiers need to be provided for non-visual accessibility.
In the above cases [3], these elements are form controls and technically are user interface elements. So ARIA may be applied if needed.
If one fails to use native HTML LABEL association without good reason and relies solely on ARIA, the outcome is less robust. In other words, accessibility benefits of the HTML label tag are not fully available to users. This is a disservice to accessibility. 

The examples for text alternative computation in the ARIA specs[2] also illustrate only user interface elements and not static content. The specs apply to Rich Internet Applications and not static HTML content. 
The text alternative computation logic surely applies when one repurposes, say, a standard BUTTON or SELECT control to work like a slider by assigning a new role like
 <button class="slider Thumb" role="slider"></button> 
as illustrated on
http://blog.paciellogroup.com/2008/05/aria-slider-part-1/

Also note other unequivocal statements in the specs such as, “Authors SHOULD provide a dialog label. Labels may be provided with the aria-label or aria-labelledby attribute if other mechanisms are not available”. … 
Note the “if other mechanisms are not available”. This is in the context of Role=dialog.

So, it is not right to simply extract the accessible name computation logic out of the ARIA specs and apply them out of context in a manner not intended by the specs. 

Thanks and regards,

Sailesh Panchang

 [1] Definition of Accessible name:
http://www.w3.org/TR/wai-aria/terms#def_accessible_name
[2] Text alternative computation    at
http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
[3[ Marking up forms
http://www.deque.com/techniques-labeling-standard-html-form-controls 

[4]Note on using ARIA
http://www.deque.com/wai-aria-opinion
[5]
Using WAI-ARIA in HTML
http://rawgithub.com/w3c/aria-in-html/master/index.html

Received on Friday, 22 November 2013 20:30:15 UTC