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