This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
Spec Review/Interactive Elements
Under review:
Note reference to Command in Focus#HTML5.
Contents
James Nurthen
Command Element
Icon - it should either be noted that the icon may only be decorative as there is no ability to specify alternative text or the ability must be given for a user to specify alternative text.
The example given for the toolbar with 3 buttons needs labelling which fully describes the functionality of the buttons. They either need to be grouped in some way (and an accessible name given for that group) or they should be labeled "Align Left", "Center" and "Align Right"
Menu Element
No issues found
Commands
No issues found
Pseudo Classes
No issues found
Greg Lowney
The description of how user agent should or must handle the menu element and its contents might be overly prescriptive. There are cases where the user agent should be allowed to adjust the presentation, particularly for different screen resolutions or navigation methods, that would require going against the prescribed behaviors. It could also do more to facilitate hierarchical presentation and navigation by allowing labeled groups of items.
Use case: Nadia is blind and using a web browser with a screen reader. The document contains a menu structure created with the HTML5 menu element, and it includes some very long menus with many groups of menu items separated by horizontal rules into various groups or sections. As Nadia uses the down arrow key to navigate through the menu items, she has to pause for each one to be read to her, so traversing a long menu takes a long time and a lot of effort. She would prefer to have the menu presented to her in hierarchical fashion that uses progressive disclosure, so she could navigate through the short list of sections, and then through the short list of commands in the desired section, rather than through one long list of items.
Use case: Aidan is the opposite of Nadia. He uses an alternative input system and input is difficult for him, so he wants to reduce the number of actions he has to take. Therefore he prefers to see all the options visible at once so that he can choose one directly, rather than having to use mechanisms involving progressive disclosure. (He has even invested in a large, high-resolution monitor to support this work style.) Rather than choosing a sub-menu and then items from them, he'd rather have all the sub-menus and their items displayed together. Unfortunately, the HTML5 specification explicitly states that the menu element with a label must be presented as a sub-menu rather than displayed inline.
HTML5 Status: The current HTML5 draft specification has a few problems with this. First, it clearly spells out when user agents should render groups of menu items inline vs. as a submenu, seemingly giving the user agent no leeway to adjust for user preference. Instead, it should note that user agents may override the default presentation described. Second, much to Nadia's dismay, it strongly emphasizes the use of hr elements to divide menu items into groups, rather than recommending methods that allow providing labels for those groups. This prevents the user agent from giving her a meaningful list of sections to navigate through. It looks like some methods are probably supported, such as by using a nested menu element that's labeled by a label element rather than a label attribute, and so would by default be presented inline rather than as a submenu, but they're not discussed in detail or recommended.
Recommendation: The HTML5 specification should note that user agents may override the default presentation described in order to comply with user preferences.
Greg to file bug (cynthia looking for old bug that may be relevant) Bug 13489?
Recommendation: In order to facilitate structural or hierarchical navigation and progressive disclosure, the HTML5 specification should emphasize giving names to groupings, including to groups of menu items.
Greg to file bug (cynthia looking for old bug that may be relevant)Bug 13623
Command element and images should support different resolutions
Why allow multiple icons in different resolutions for a page icon but not for a command element icon or an img element?
Use case: Todd is working on a high resolution monitor but has moderately low vision, so he uses his browser's zoom setting so that he can read the text easily and discern the details of images. He goes to a web page that includes multiple buttons implemented using command elements, each represented by an icon. Unfortunately, since HTML5 only allows a command element to link to a single image, the browser has to use brute force methods to enlarge the image, with a result that's blocky and difficult to understand. If the author had been able to link to multiple versions of the image, each optimized for different screen resolutions or sizes, Todd could have been presented with graphical buttons he could understand.
Recommendation: HTML5 should allow the author to link a command element to multiple images optimized for different screen resolutions and zoom ratios.
It would also be beneficial to allow static images (e.g. the img element) to also link to multiple image files optimized for different resolutions, so that pages can better adapt to different screen resolutions and zoom ratios without having to resort to complex scripting. However, it could be argued that there are different priorities for the relative priority of applying this to command elements--which the user always has to identify to interact with them--and possibly static img element.
Submit WCAG technique(s) note availability of CSS Image Values and Replaced Content http://www.w3.org/TR/2011/WD-css3-images-20110712/
Greg to file bug about issue, noting there are solutions but we don't know which ones will shake out (CSS Image Values, multi-resolution images, script solutions) Bug 13514