HTML 5 spec comments

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.

The compiled comments are attached as an rtf document and spreadsheet. 
The text version is copied below.


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