UAWG Comments on HTML5
The following comments have been submitted by members of the User Agent Accessibility Guidelines Working Group (UAWG).  The Working Group's review of HTML5 is on-going and more comments will be submitted when identified by the group members.  

Issue#: UAWG01
Section: General
Version: 
Comment: massive document, changing frequently. HTML so complex, and nuanced, concerns about missing accessibility issues
Reviewer: Jim Allan

Issue#: UAWG02
Section: General
Version: 
Comment: Fallback content - no user agent provides a mechanism to retrieve
author created fallback content
3.2.5.1.6 Embedded content - definition of fallback content
3.2.5.3 Paragraphs
4.8.4 The embed element
4.8.5 The object element
4.8.7 The video element
4.8.8 The audio element
4.8.11 The canvas element... (lots more in the document)
Reviewer: Jim Allan

Issue#: UAWG
Section:  3.2.1 Semantics
Version: 
Comment: 3.2.1 Semantics ISSUE-41 (Decentralized-extensibility) blocks
progress to Last Call. HUGE problem for AT. Possible new elements created that no AT is familiar.
Reviewer: Jim Allan

Issue#: UAWG04
Section:  3.2.6 Annotations
Version: 
Comment: 3.2.6 Annotations for assistive technology products - are these in sync with ARIA
Reviewer: Jim Allan

Issue#: UAWG05
Section: 7.1 The hidden attribute*
Version: 
Comment: It's important to give users the ability to discover and navigate content when authoring tools are used incorrectly. The hidden attribute is a good example.

*Excerpt: "The **hidden **attribute must not be used to hide content that could legitimately be shown in another presentation, for example..." *

On occasion it will be, however, and full accessibility means the user needs some way to override this in order to deal with incorrectly rendered pages.
Reviewer: Kim Patch

Issue#: UAWG06
Section:  7.3 Scrolling elements into view
Version: 
Comment: In a perfect world there'd be a way for the user to override automatic 
scrolling. Automatic scrolling can make the cursor jump in ways that causes the 
user to go through extra steps to get back to what he was doing. This is a special hardship for some users. This is another example of allowing for full accessibility by giving the user a way to override inappropriate design.
Reviewer: Kim Patch

Issue#: UAWG07
Section: 7.4.3 document-level focus APIs
Version: 
Comment: The user needs some way to override/hold off focus changes. User macros including speech commands execute over time. Unwanted focus switches can produce bad results.

In addition, speech users don't necessarily change the focus by moving the mouse -- this makes them more likely to get caught with bad focus changes. This is a third example of allowing for full accessibility by giving the user a way to override inappropriate design.
Proposal: 
UAAG Implications: 
Reviewer: Kim Patch

Issue#: UAWG08
Section: 7.7 The content editable attribute
Version: 
Comment: Move the carrot

    *Excerpt: ... "this could be triggered as the default action of
    keydown events with various key identifiers and as the default
    action of Mousedown events *

It's important to provide a way to do everything through the keyboard -- this seems like an either/or. (For speech users, selecting text using keyboard commands is easier, requires fewer steps and is more precise than selecting text using mouse commands.)
Reviewer: Kim Patch

Issue#: UAWG09
Section: 7.7 The content editable attribute
Version: 
Comment: Select and move non-editable elements nested inside editing hosts

    *Excerpt: UAs should offer a way for the user to move images and
    other non-editable parts around the content within an editing host.
    This may be done using the drag and drop mechanism.*

All drag and drop needs to be accessible using key navigation and cut-and-paste. (For speech users, drag-and-drop using key navigation and cut paste is less prone to mistakes and fewer steps than using mouse commands. )
Reviewer: Kim Patch

Issue#: UAWG10
Section: 7.9 Drag and drop
Version: 
Comment: Again, needs to be accessible using key navigation and cut-and-paste. It's also important to have undo enabled for drag-and-drop.

    *Excerpt: On a visual medium with a pointing device...*
    *On media without a pointing device...*

Even if media has pointing device needs keyboard option
Reviewer: Kim Patch

Issue#: UAWG11
Section: 7.10 Undo History
Version: 
Comment: This should include drag and drop
Reviewer: Kim Patch

Issue#: UAWG12
Section: 7.1, the hidden attribute
Version: http://dev.w3.org/html5/spec/Overview.html
Comment: Accessibility APIs must honor this. User agents will need to ensure to reflect the state of this attribute in their accessibility APIs.  This may be stating the obvious but is worth calling out since there are various situations today where AT products do or do not show the same text that is visually displayed and this is another potential variable to keep in mind.
UAAG Implications:  We need to develop some kind of test criteria around this, especially for AT support/compatibility
Reviewer: Kelly Ford

Issue#: UAWG13
Section: 7.3 scroll into view
Version: http://dev.w3.org/html5/spec/Overview.html
Comment: What should happen to focus here, especially keyboard focus?  This is an interesting one.  The GL talks about calling attention at times as in The scrollIntoView([top]) method, when called, must cause the element on which the method was called to have the attention of the user called to it.  Exactly what this means for accessibility and how UA should do this in an accessible fashion are good things to think about.
Reviewer: Kelly Ford

Issue#: UAWG14
Section: 7.9 drag and drop
Version: http://dev.w3.org/html5/spec/Overview.html
Comment: This still seems plagued with accessibility actions.  This needs more discussion around accessibility.  Is it enough to say that the start/end point experiences of the drag/drop must be accessible.  What about everything that can happen along the journey?  I think we need to discuss this one further with PF and ourselves.
Reviewer: Kelly Ford

Issue#: UAWG15
Section: 4.10 Forms
Version: http://dev.w3.org/html5/spec/forms.html#forms
Comment: Overall the proposal to allow unscripted client-server interaction thereby taking the onerous off the page author and into the browser is a huge benefit to accessibility. This means that validating forms, checking input and so on will be customized across sites with no reliance on JavaScript. Designers will not have to build form validation from the ground up each time and users can enjoy some  consistency, less breakage and so on.
Reviewer: Henny Swan

Issue#: UAWG16
Section: 4.10 Forms
Version: http://dev.w3.org/html5/spec/forms.html#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 I see as 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).

My other fear is that if forms validation can not be styled without JavaScript page authors may skip using HTML5 webform validation as it messes up their design. We then get to a situation where we have developers refusing to adopt webforms in HTML5 in favour of their own styled forms which potentially could be inaccessble. Users in turn miss out.

Anecdotally I know of a web designer who works predominantly with users with cognitive problems and wont use webforms if they can't easily be styled without JavaScript.
Proposal: require that all error validation be stylable by the page author without relying on JavaScript. Not sure if this is in scope of HTML5 or is under UAAG. I'm told this is not so easy for a UA to do and that if we want to make the default error messages styleable, we would need to approach the CSSWG with the problem and have them find a solution to make them styleable.  Apparently it could possibly work if they provided some sort of pseudo-element. 
UAAG Implications: Do we have a UAAG guideline to enforce this / should it be covered in HTML5? Is it the case that UAAG can only say that the messages themselves need to be accessible, but can't say anything about making them author-styleable?
Reviewer: Henny Swan

Issue#: UAWG17
Section: 4.10 Forms
Version: http://dev.w3.org/html5/spec/forms.html#forms
Comment: Date pickers: Date pickers should be both keyboard accessible and able to be  magnified in the browser. I think this is beyond the scope of HTML5  itself and covered in UAAG but mention it just to clarify.
UAAG Implications: This should be covered in UAAG for  keyboard accessibility I'm guessing. 
Reviewer: Henny Swan

Issue#: UAWG18
Section:  7.6 list-item 2 
Version: 
Comment: So looking at this further, I see that in 7.6 list-item 2 and 3.3 of the HTML5 spec on accesskeys, that 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. In this case what about a caveat that if the context menu is in focus then a single keystroke without a modifier key is sufficient?
Reviewer: Simon Harper

Issue#: UAWG19
Section: 3.3
Version: 
Comment: So looking at this further, I see that in 7.6 list-item 2 and 3.3 of the HTML5 spec on accesskeys, that 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. In this case what about a caveat that if the context menu is in focus then a single keystroke without a modifier key is sufficient?
Reviewer: Simon Harper

Issue#: UAWG20
Section: 7.10.5 Draggability
Version: 
Comment: I have no idea how this can be addressed, while selection can be easy, understanding the location on a page for a drop/release may be problematic without some form of browser based auditory feedback?
Reviewer: Simon Harper

Issue#: UAWG21
Section: 3.3.3.8 Embedded Links to Non-Visible Data
Version: 
Comment: 3.3.3.8 Embedded Links to Non-Visible Data - this could be really useful and a great accessibility feature, but as there is no concept of interoperability beyond the site (as it is site bespoke) then we need to ensure that this kind of data is readable by the AT and maybe even the semantics of the interaction expressed in someway.
Reviewer: Simon Harper

Issue#: UAWG22
Section: 3.3.5 Orphan Nodes in Content Models
Version: 
Comment: 3.3.5 Orphan Nodes in Content Models - this could be problematic if  the node cannot be accessed by AT, especially if it is going to  modify the DOM based on a user event, but there is no way of telling  what that modification will be.
Reviewer: Simon Harper

Issue#: UAWG23
Section: 3.3.5.1.6 and .7 Embedded and Interactive Content
Version: 
Comment: 3.3.5.1.6 and .7 Embedded and Interactive Content - activation behaviour and pre-click activation - there are too many opportunities for some accessibility nightmare here so it maybe worth reading these points and then discussing them.
Reviewer: Simon Harper

Issue#: UAWG24
Section: 3.2.4 
Version: 
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.
Reviewer: Simon Harper

Issue#: UAWG25
Section: General
Version: 
Comment: There are elements which are VERY VERY GOOD and the HTML5 crew should be congratulated from the nice explicit semantics of menu and the like. However, they then mess it up with elements such as 'small' - convenient for a visual rendering, good for the designer, but without a concept of the semantics of the thing it encloses - it does not say what the thing is. Would it not be better to enable overloading of an element and style combination into an element that is good for the designer, but because its base element type is known (and this has explicit semantics) AT gets a better idea of what the thing actually is as opposed to how it should be rendered?
Reviewer: Simon Harper

Issue#: UAWG26
Section: General
Version: 
Comment: I've not seen a good definition of quirks or limited- quirks modes.
Reviewer: Simon Harper

Issue#: UAWG27
Section: General
Version: 
Comment: It seems to me we are going to need far better validation  
and conformance tools to check that possible DOM modifications in the  
scripts are accessible - otherwise an html page - containing pretty  
much nothing will validate as OK, but there may be a huge amount of  
scripting which will enact inaccessible DOM updates on the client.
Reviewer: Simon Harper

Issue#: UAWG28
Section: 11.2.5 Fonts and colors
Version: http://dev.w3.org/html5/spec/the-xhtml-syntax.html#fonts-and-colors
Comment: 11.2.5 Fonts and colors states:  
<quote>
The article, aside, nav, and section elements are expected to affect the 
font size of h1 elements, based on the nesting depth. If x is a selector 
that matches elements that are either article, aside, nav, or section 
elements, then the following rules capture what is expected:

@namespace url(http://www.w3.org/1999/xhtml);

x h1 { font-size: 1.50em; }
x x h1 { font-size: 1.17em; }
x x x h1 { font-size: 1.00em; }
x x x x h1 { font-size: 0.83em; }
x x x x x h1 { font-size: 0.67em; }
</quote>

Issue: 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. Automatic reduction of the size is unnecessary and will decrease access for users with low vision.
Proposal: Remove the section. Nested elements should not have the containing text size reduced automatically.  The author can choose to reduce the size of nested text through CSS, but it should not happen to font sizes automatically.
Reviewer: Jeanne Spellman

Issue#: UAWG29
Section: HTML section: 11.2.3 Margins and padding
Version: http://dev.w3.org/html5/spec/the-xhtml-syntax.html#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 passed to the Assistive Technology and the user may not be able to see the text that does not fit in the container.
Proposal: Add after chart (Attribute value/'overflow' value)
When the user has increased the text size of the document, the 'overflow' value should always be set to 'scroll'.
UAAG Implications: We have addressed this for graphics: 3.10.5 Scrollbars: Graphical viewports include scrollbars if the rendered content (including after user preferences have been applied) extends beyond the viewport dimensions, overriding any values specified by the author. (Level A)

I propose adding a new SC in 3.6 Provide text configuration.  Proposal: 
3.5.x  Container overflow options. When text resized by the user overflows the containing element the user has the option to either:
(a) expand the size of the containing element to display the text or
(b) to override any author setting preventing scrollbars in order to display all of the text
Reviewer: Jeanne Spellman

Issue#: UAWG30
Section: 4.8.7 Video
Version: http://www.whatwg.org/specs/web-apps/current-work/
Comment: Biggest issue:  Accessibility of the video content left unspecified. No mechanism for defining or providing captions as part of the Video element.  This is unfortunate, in that W3C's very own proposed DXFP [1], and even SMIL Text [2] provide everything needed to create accessible video content (assuming the authoring tools and browser support were there).

Given the controversory over video codec support, captioning is apparently not being given attention.  The spec says:

"4.8.10.10 User interface

The controls attribute is a boolean attribute. If present, it indicates that the author has not provided a scripted controller and would like the user agent to provide its own set of controls.

If the attribute is present, or if scripting is disabled for the media element, then the user agent should expose a user interface to the user. This user interface should include features to begin playback, pause playback, seek to an arbitrary position in the content (if the content supports arbitrary seeking), change the volume, and show the media content in manners more suitable to the user (e.g. full-screen video or in an independent resizable window). Other controls may also be made available.

User agents should provide controls to enable or disable the display of closed captions associated with the video stream, though such features should, again, not interfere with the page's normal rendering."

It is not clear to me that the spec has specified/will specify a standard API that would allow a UA to query if media (either audio or video) ".hasCaptions", or to otherwise get at the text of the captions(or the language, etc).

If the UA (or AT) is supposed to have the ability to control captions, shouldn't the video element have defined the needed properties to query and control the caption content in the video being loaded/played? This seems very vague and a big gap for such a visible feature of the HTML5 spec. Failing any further details in the HTML5 spec, it is imperative that the UA spec will  address the missing details.

Silvia Pfeiffer [3] has been active in looking at HTML5 video accessibility, and has a proposal for iText as a means of integrating captioning into HTML5 video.  This is great work, to be lauded, but I am still at a loss for the failure to integrate existing W3C work such as DXFP for captioning.  I must be missing something.

No mention of descriptive video or alternate audio tracks.  Again, is this something that *may* be in the video source, pr authored using a combination of scripting and the audio/video elements? Unclear, and should be addressed.

My take on HTML5 video is that, based on the current spec, implementation of captioning/dvs will will primarily occur via authored scripting around the video element. Perhaps some browser vendor will build it in a non-standard way. It should be defined more fully in the HTML5 spec.

[1] http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/
[2] http://www.w3.org/TR/SMIL3/smil-text.html
[3] http://blog.gingertech.net/2009/07/29/first-experiments-with-itext/
Reviewer: Markku Hakkinen

Issue#: UAWG31
Section: 4.8.7 Video 
Version: http://www.whatwg.org/specs/web-apps/current-work/
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.
Reviewer: Jim Allan