HTML5 Comments from the User Agent Accessibility Guidelines Working Group

The following comments have been gathered by members of the User Agent Accessibility Guidelines Working Group (UAWG) which is part of the Web Accessibility Initiative Technical Activity.  The UAWG Working Group's review of HTML5 is on-going and more comments will be submitted when identified by the group members.  The following comments were on the version http://dev.w3.org/html5/spec/  during the week of 24 August – 4 September. Other WAI Working Groups are reviewing the HTML5 Working Draft and their comments may be channeled into the Joint Task Force discussion.  Please reply back to UAAG WG at w3c-wai-ua@w3.org and cc: the WAI Protocols & Formats Working Group at w3c-wai-pf@w3.org 

Issue#: UAWG24
Section: 3.2.4 
Comment: 3.2.4 There are many references to mutation events 'firing as appropriate', but without knowing when that is - UAs can make interpretations about what and when an event will fire - indeed some sections state that no mutation events will fire. Consistent rules on firing mutation events are needed for assistive technologies to capture and communicate mutation events to users. 
Issue#: UAWG04
Section:  3.2.6 Annotations
Comment: 3.2.6 “Annotations for assistive technology products” section is not clear whether these are in sync with WAI-ARIA. WAI-ARIA is in Last Call and is being implemented by browsers and assistive technologies. Any conflict between HTML5 and WAI-ARIA must be identified and resolved.  Browser and assistive techology developers  need confirmation that these two sets of standards are not in conflict. 
Issue#: UAWG21
Section: 3.3.3.8 Embedded Links to Non-Visible Data
Comment: 3.3.3.8 Embedded Links to Non-Visible Data could be a useful  accessibility feature, but as there is no concept of interoperability beyond the site (as it is site bespoke) then we need to 1) ensure that this kind of data is readable by the assistive technology and 2)  the semantics of the interaction are expressed in a readable fashion.
Issue#: UAWG30
Section: 4.8.7 Video [Captions]
Comment: 1) Captions provide a means to understand the video for those who are deaf, hard of hearing, non-primary language, or watching in a silent environment.  No mechanism for defining or providing captions is specified as part of the Video element, therefore implementation of captioning will primarily occur via authored scripting around the video element. It needs to be defined more fully in the HTML5 spec to ensure that browsers implement it in a standard way.  It is not clear that the spec has specified/will specify a standard API that would allow a user agent to query if media (either audio or video) ".hasCaptions", or to otherwise get at the text of the captions(or the language, etc). W3C's proposed DXFP [1], and even SMIL Text [2] provides guidance to create accessible video content (assuming the authoring tools and browser support were there).  

2) Since the user agent is supposed to have the ability to control captions,  the video element needs to define the needed properties to query and control the caption content in the video being loaded/played. 

[1] http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/
[2] http://www.w3.org/TR/SMIL3/smil-text.html

Issue#: UAWG32
Section: 4.8.7 Video [Descriptive or alternate audio tracks]
Comment: There is no mention of descriptive video or alternate audio tracks, which are needed by users who cannot see the video, or need to hear the audio in another language.  It is unclear whether this is  something that *may* be in the video source, or authored using a combination of scripting and the audio/video elements.  This needs to be clearly defined.  
Issue#: UAWG31
Section: 4.8.7 Video [Controls]
Comment: The User Agent should be required to provide the controls/interface-elements for media (audio, video, etc.). The author should be able to style or script for extended functionality. The core functionality - start/stop, pause, seek, volume, size (full screen), caption track(s)- on/off/fg-bg color/location, descriptive video(s), should not be written by millions of authors.
Issue#: UAWG16
Section: 4.10 Forms
Comment: Form validation: Under form validation there is no stipulation that validation errors should be stylable by the page author using CSS and are currently only available as per how the UA styles them unless the page author knows JavaScript.  This is an issue if browsers simply implement an arbitrary styling that some users find hard to read. As such there needs to be scope for validation errors to be stylable (without relying on JavaScript) or browser implementations to be as readable / accessible as possible (the latter being pretty subjective).
Issue#: UAWG06
Section:  7.3 Scrolling elements into view
Comment:  Automatic scrolling can make the cursor jump in ways that causes the user to go through extra steps to get back to what s/he  was doing. This is a special hardship for some users who have limited hand mobility and/or speech input users. There needs to be a way for the user to override automatic scrolling.
Issue#: UAWG07
Section: 7.4.3 document-level focus APIs
Comment: Unwanted focus switches can produce bad results. Visually impaired users can lose the focus, or magnifier users can have the focus move to a part of the page that is off-screen.  User macros including speech commands execute over time. Speech users don't necessarily change the focus by moving the mouse -- this makes them more likely to get caught with bad focus changes.   The user needs some way to override/hold off focus changes. 
Issue#: UAWG18
Section:  7.6 list-item 2 and 3.3
Comment: In 7.6 list-item 2 and 3.3 of the HTML5 spec on accesskeys,  only a single key is allowed as opposed to multiple sequential keys, however, when you add this to the concept of the context menu in 4.11.5.3 it seems that the general model of interaction, and importantly exploration of the interface, becomes broken as a single keystroke without a modifier key cannot be allocated. While this follows on the mac OS, the intuitive sequential keystrokes of Windows and Linux will break. We recommend that if the context menu is in focus then a single keystroke without a modifier key is sufficient.
Issue#: UAWG09
Section: 7.7 The content editable attribute (drag and drop implementation)
Comment:  Select and move non-editable elements section does not specifically require keyboard access.  All drag and drop needs to be accessible using key navigation and cut-and-paste. Users with limited mobility have difficulty or are unable to use a mouse.  Speech users are less prone to mistakes and have fewer steps with drag-and-drop using key navigation and cut paste, than with using mouse commands. 
Issue#: UAWG08
Section: 7.7 The content editable attribute (move the carat)
Comment: The “Move the carat” section is phrased so it is either/or choice of mouse and keyboard when it should be phrased as an “and” – both mouse and keyboard options are required.  For people with limited mobility or speech input users,  we recommend selecting text using keyboard commands since it is easier, requires fewer steps and is more precise than selecting text using mouse commands. 
Issue#: UAWG10
Section: 7.9 Drag and drop
Comment: Drag and drop needs to be accessible using key navigation and cut-and-paste. It's also important to have undo enabled for drag-and-drop. Even if media has pointing device, it also needs keyboard option for those users with limited mobility or using speech input assistive technology. 
Issue#: UAWG11
Section: 7.10 Undo History
Comment: Undo History  needs to include Undo of drag and drop actions.  Users with limited hand mobility are more prone to movement mistakes. Undo of drag and drop is equally important as other Undo actions. 
Issue#: UAWG28
Section: 10.2.5 Fonts and colors
Comment:  Automatic reduction of the font size of H elements nested in the article, aside, nav, and section elements will decrease access for users with low vision. Users with low vision adjust font sizes to the minimum size needed for comfortable reading. Many users with low vision do not use assistive technology, but rather adjust to the largest font size supported by the user agent.  Reducing the size of the font - particularly a text-dense element like "article" - increases the imbalance between font sizes in other parts of the page (e.g. the user would be forced to increase font size for the article text to the point where the font size in the non-nested parts of the page are enlarged so much as to overflow their containers.)  We recommend that nested elements not have the containing text size reduced automatically.  
Issue#: UAWG29
Section: HTML section: 10.2.3 Margins and padding
Comment: If the user wishes to increase the size of text in an iframe or other container element, the text may overflow the container. When text overflows the size of a box and the attribute value is set so that the overflow value is "hidden", the overflow text may not be displayed or passed to the Assistive Technology.  When the user has increased the text size of the document, the 'overflow' value needs to default to 'scroll'.