HTML 5 spec review

This is a planning document for the Web Accessibility Initiative Working Groups to support the Protocols and Formats Working Group in executing a formal review of the HTML 5 specification (Editor's Draft as of August 2009). The Table of Contents from the HTML specification is shown along with reviewers assigned to each section.

Section Reviewer(s) Status
1 Introduction    
1.1 Background
1.2 Audience
1.3 Scope
1.4 History
1.5 Design notes
1.6 Relationships to other specifications
1.8 Structure of this specification
1.9 A quick introduction to HTML
2 Common infrastructure    
2.1 Terminology
2.2 Conformance requirements
2.3 Case-sensitivity and string comparison Thomas Logan  
2.4 Common microsyntaxes
2.5 URLs Gottfried Zimmerman sent
2.6 Fetching resources
2.7 Character encodings Gottfried Zimmerman  
2.8 Common DOM interfaces
3 Semantics, structure, and APIs of HTML documents Loretta Guarino Reid Loretta comments Sent; discussed in caucus 25 September 2009 and 2 October 2009
3.1 Introduction
3.2 Documents
3.3 Elements
3.4 APIs in HTML documents
3.5 Interactions with XPath and XSLT
3.6 Dynamic markup insertion Loretta Guarino Reid, James Craig
4 The elements of HTML Sofia Celic Sent
4.1 The root element
4.2 Document metadata
4.3 Scripting
4.4 Sections Joshue O'Connor  
4.5 Grouping content Joshue O'Connor  
4.6 Text-level semantics Joshue O'Connor  
4.7 Edits Joshue O'Connor  
4.8 Embedded content Ben Caldwell Ben sent issues; Jan (AUWG) sent issues
4.9 Tabular data Sofia Celic, Kelly Ford?  
4.10 Forms Cynthia Shelly, Gregory Rosmaita  
4.11 Interactive elements Cynthia Shelly Submitted in progress
4.12 Miscellaneous elements Sofia Celic  
4.13 Matching HTML elements using selectors Ben Caldwell  
5 Microdata Jon Gunderson  
5.1 Introduction
5.2 Encoding microdata
5.3 Microdata DOM API
5.4 Predefined vocabularies
5.5 Converting HTML to other formats
6 Web browsers Gez Lemon?  
6.1 Browsing contexts
6.2 The WindowProxy object
6.3 The Window object
6.4 Origin
6.5 Scripting Steve Faulkner Steve: Nothing problematic except for ASCII art in spec
6.6 Timers
6.7 User prompts Steve Faulkner, Kelly Ford
6.8 System state and capabilities Steve Faulkner
6.9 Offline Web applications James Craig James: No issues found
6.10 Session history and navigation James Craig James: No issues found
6.11 Browsing the Web Joseph Scheuhammer James: (typo)
6.12 Links Sally Cain James: sent; Sally: sent
7 User Interaction Ben Caldwell, Joshue O'Connor  
7.1 Introduction
7.2 The hidden attribute
7.3 Activation
7.4 Scrolling elements into view
7.5 Focus
7.6 The accesskey attribute
7.7 The text selection APIs
7.8 The contenteditable attribute Frank Olivier, James Craig  
7.9 Spelling and grammar checking    
7.10 Drag and drop Rich actioned to review  
7.11 Undo history    
7.12 Editing APIs
8 Communication James Nurthen No issues found
8.1 Event definitions
8.2 Cross-document messaging
8.3 Channel messaging
9 The HTML syntax Sally Cain

Comments sent 20 Aug 09

9.1 Writing HTML documents
9.2 Parsing HTML documents
9.3 Namespaces David Bolter  
9.4 Serializing HTML fragments
9.5 Parsing HTML fragments
9.6 Named character references
10 The XHTML syntax Thomas Logan  
10.1 Writing XHTML documents
10.2 Parsing XHTML documents
10.3 Serializing XHTML fragments
10.4 Parsing XHTML fragments
11 Rendering Tony Ross, Kelly Ford  
11.1 Introduction
11.2 The CSS user agent style sheet and presentational hints
11.3 Replaced elements
11.4 Bindings Jon Gunderson  
11.5 Frames and framesets Cynthia Shelly  
11.6 Interactive media Sean Hayes  
11.7 Print media Cynthia Shelly  
11.8 Interaction with CSS Cynthia Shelly  
12 Obsolete features Loretta Guarino Reid Sent
12.1 Obsolete but conforming features
12.2 Non-conforming features
12.3 Requirements for implementations
13 Things that you can't do with this specification because they are better handled using other technologies that are further described herein    
13.1 Localization
13.2 Declarative 3D scenes

1 Introduction

1.1 Background

1.2 Audience

1.3 Scope

1.4 History

1.5 Design notes

1.5.1 Serializability of script execution

1.5.2 Compliance with other specifications

1.6 Relationships to other specifications

1.6.1 Relationship to HTML 4.01 and DOM2 HTML

1.6.2 Relationship to XHTML 1.x


1.8 Structure of this specification

1.8.1 How to read this specification

1.8.2 Typographic conventions

1.9 A quick introduction to HTML

2 Common infrastructure

2.1 Terminology

2.1.1 XML

2.1.2 DOM trees

2.1.3 Scripting

2.1.4 Plugins

2.1.5 Character encodings

2.1.6 Resources

2.2 Conformance requirements

2.2.1 Dependencies

2.2.2 Extensibility

2.3 Case-sensitivity and string comparison

2.4 Common microsyntaxes

2.4.1 Common parser idioms

2.4.2 Boolean attributes

2.4.3 Keywords and enumerated attributes

2.4.4 Numbers Non-negative integers Signed integers Real numbers Ratios Percentages and lengths Lists of integers Lists of dimensions

2.4.5 Dates and times Months Dates Times Local dates and times Global dates and times Weeks Vaguer moments in time

2.4.6 Colors

2.4.7 Space-separated tokens

2.4.8 Comma-separated tokens

2.4.9 Reversed DNS identifiers

2.4.10 References

2.5 URLs

Gottfried: The „willful violation“ of RFC3986 (see note at bottom of the section) in using the term „URL“ is not good.  It confuses users and works against a harmonization of existing standards.  A replacement term for “URL” should be found. Cf. MC: not a PFWG comment.

2.5.1 Terminology

2.5.2 Dynamic changes to base URLs

2.5.3 Interfaces for URL manipulation

2.6 Fetching resources

2.6.1 Protocol concepts

2.6.2 Encrypted HTTP and related security concerns

2.6.3 Determining the type of a resource

2.7 Character encodings

2.8 Common DOM interfaces

2.8.1 Reflecting content attributes in DOM attributes

2.8.2 Collections HTMLCollection HTMLAllCollection HTMLFormControlsCollection HTMLOptionsCollection

Gottfried: Is it possible to create and modify <optgroup> elements by JavaScript?  <optgroup>s are a useful mechanism for structuring options, in particular for users with screenreaders and magnifiers.  I don’t see this here, but maybe i am missing something. MC: add method does allow optgroup; suggest not submitting. HTMLPropertyCollection

2.8.3 DOMTokenList

2.8.4 DOMSettableTokenList

2.8.5 Safe passing of structured data

2.8.6 DOMStringMap

2.8.7 DOM feature strings

2.8.8 Exceptions

2.8.9 Garbage collection

3 Semantics, structure, and APIs of HTML documents

3.1 Introduction

3.2 Documents

3.2.1 Documents in the DOM

3.2.2 Security

3.2.3 Resource metadata management

3.2.4 DOM tree accessors

3.3 Elements

3.3.1 Semantics

UAWG03: ISSUE-41 (Decentralized-extensibility) blocks progress to Last Call. HUGE problem for AT. Possible new elements created that no AT is familiar. MC: issue in "raised" state; should add a PFWG +1 but not sure of mechanism.

3.3.2 Elements in the DOM


The standard Element interface includes an attribute, "icon". I'm not sure of its purpose, but we should make sure that these icons have text equivalents available, too, if needed.

Cynthia: icon is part of a "command API" that also has a label. That would need to be required. Cynthia looking into this.

MC: label is present; no need to comment.

3.3.3 Global attributes The id attribute The title attribute


Accessibility uses of title problematic when title may have other uses as well.

Steve has an issue open about title.

MC: suggest reengineering title attribute, moving accessibility use cases to label attribute or something. But this would be a big change that has to propagate through many elements. The lang and xml:lang attributes The xml:base attribute (XML only) The dir attribute The class attribute The style attribute Embedding custom non-visible data

UAWG21: 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. MC: this is related to extensibility and we should review in context of extensibility solution and what our priorities for that are.

3.3.4 Element definitions

3.3.5 Content models

UAWG22: 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. MC: the node isn't meaningful until it gets inserted into the document at an appropriate place, at which point AT can use it. Don't think this is an issue. Kinds of content Interactive content

UAWG23: 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. MC: discuss. My biggest concern is that it's all mouse-biased. Beyond that, I can't figure out what it does. Transparent content models Paragraphs

3.4 APIs in HTML documents

3.5 Interactions with XPath and XSLT

3.6 Dynamic markup insertion

3.6.1 Controlling the input stream

3.6.2 document.write()

3.6.3 document.writeln()

3.6.4 innerHTML

3.6.5 outerHTML

3.6.6 insertAdjacentHTML()

4 The elements of HTML

4.1 The root element

4.1.1 The html element

4.2 Document metadata

4.2.1 The head element

4.2.2 The title element

4.2.3 The base element

Sofia: The base element allows for a target attribute that controls the context in which target URLs will be displayed. The target attribute value potentially changes the context for all links in the document. Applicable WCAG 2.0 Success Criterion: 3.2.5 (Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)) MC: Suggest a user agent technique to provide an override mechanism, and a WCAG technique around the issues.

4.2.4 The link element

4.2.5 The meta element Standard metadata names Other metadata names Pragma directives Other pragma directives Specifying the document's character encoding

4.2.6 The style element

Sofia: No mention of encouraging authors to make their applications degrade gracefully in the absence of style support or to allow for alternate presentation. Applicable WCAG 2.0 Success Criteria: SC under Guideline 1.3 (Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.) MC: think this is a design issue, not a spec issue.

MC: I don't understand what the title attribute does ("alternative style sheet sets" is not linked to a definition) and what accessibility implications it might have.

MC: Handling of alternate style sheets not defined (alternate to what?).

4.2.7 Styling

4.3 Scripting

4.3.1 The script element Scripting languages Inline documentation for external scripts

4.3.2 The noscript element

4.4 Sections

Josh: Does the algorithm give an idea of how this kind of content would be parsed by legacy UAs? Discuss.

Josh: In the “Sectioning Root” [2], the spec states “Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1  elements, or to use elements of the appropriate rank  for the section's nesting level.”

Does this mean that multiple <h1>s can be used in a single doc? Does this go against current best practice?

The spec states that:

For example, the following is correct:

 					<p>Apples are fruit.</p>
 					<p>They taste lovely.</p>
 					<p>Red apples are sweeter than green ones.</p>
 					<p>Apples come in various colors.</p>

is it? Seems like an incorrect placing of <h1> to me.

4.4.1 The body element

4.4.2 The section element

Josh: Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.

Does this break the model of only allowing use of one <h1> per html doc.

4.4.3 The nav element

Josh: The spec state:

“User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.”

How will this be done in the UA? Will they activate a linked nav element like they do a href? Or will the user be able to jump to a <nav> element the same way user can browse by headings etc.

How will this work with aria role=”navigation” in a UA?

Josh: The spec gives an example:

“In the following example, there are two nav  elements, one for primary navigation around the site, and one for secondary navigation around the page itself.”

They seem a little pointless. Both are just lists links wrapped in <nav>. They can link to items on the same page, or on separate pages. The user can often gain this information from good descriptive link text. Again how will this work with aria role=”navigation”.

4.4.4 The article element

[reaction to comment 126] The first paragraph is not clear whether it means an article can contain a widget or be a widget (have a widget role). We believe it should be able to contain a widget but be default should not be a widget. By default, articles should be contained in documents, not in applications.

4.4.5 The aside element

4.4.6 The h1, h2, h3, h4, h5, and h6 elements

Josh: Are the examples equivalent?

Is this advice confusing? Does this use of headings represent a shift in the way HTML headings have been used in the past? Discuss.

4.4.7 The hgroup element

Josh: How will that work in practice with screen readers? Will child headings contained in the <hgroup> be ignored? In particular legacy UAs? Will legacy UAs just not parse the <hgroup> element and just parse the contained headings?

Should alternative alternative titles, or taglines etc be marked up like this in the fist place?

4.4.8 The header element

Josh: “The header element is not sectioning content; it doesn't introduce a new section.”

The header element does not take part in the outline algorithm. However, should it not do this? Is it not implied that a header has an associated following section? Seems counter intuitive. Or is this by design?

4.4.9 The footer element

4.4.10 The address element

4.4.11 Headings and sections Creating an outline Distinguishing site-wide headings from page headings

4.5 Grouping content

4.5.1 The p element

4.5.2 The hr element

4.5.3 The br element

4.5.4 The pre element

4.5.5 The dialog element

4.5.6 The blockquote element

4.5.7 The ol element

4.5.8 The ul element

4.5.9 The li element

4.5.10 The dl element

4.5.11 The dt element

4.5.12 The dd element

4.5.13 Common grouping idioms Tag clouds

4.6 Text-level semantics

4.6.1 The a element

4.6.2 The q element

4.6.3 The cite element

4.6.4 The em element

4.6.5 The strong element

4.6.6 The small element

4.6.7 The mark element

4.6.8 The dfn element

4.6.9 The abbr element

4.6.10 The time element

4.6.11 The progress element

4.6.12 The meter element

4.6.13 The code element

4.6.14 The var element

4.6.15 The samp element

4.6.16 The kbd element

4.6.17 The sub and sup elements

4.6.18 The span element

4.6.19 The i element

4.6.20 The b element

4.6.21 The bdo element

4.6.22 The ruby element

4.6.23 The rt element

4.6.24 The rp element

4.6.25 Usage summary

4.6.26 Footnotes

4.7 Edits

4.7.1 The ins element

4.7.2 The del element

4.7.3 Attributes common to ins and del elements

4.7.4 Edits and paragraphs

4.7.5 Edits and lists

4.8 Embedded content


  1. This section includes a number of mechanisms for embedding content, but the <img> and <area> elements are the only elements that include a specific mechanism for providing a short text alternatives (@alt). The need for a mechanism to include a short text alternative (label) for the embedded content is no different for elements such as embed, video, audio, canvas, MathML and SVG. Since the ability for the embedded content to provide a text alternative directly will vary across formats, content types and authoring practices, HTML5 should include support for the alt attribute or a similar mechanism (ex. aria-labelledby) for each of these elements and the conformance requirements regarding its presence should be consistent for each element.
  2. From an accessibility perspective, HTML5 should describe a model for fallback content that allows the user to choose from any available fallbacks. The problem with specifying that fallback content should only be "used when an external resource cannot be used", is that it puts users in the position of having to guess about the accessibility of the content on different sites and to reconfigure their browser to find out if they guessed correctly. For example, an author on one site might embed captioned video that requires a plugin in order to be rendered with no fallback while an author on a second site uses the same plugin to include a video, omits captions, but provides fallback content that includes a text transcript of the video. The problem is that a deaf user who has the required plugin installed will get the captions on the first site, but will likely miss that there's no fallback on the second site entirely. Similarly, if the same user does not have the required plugin (or has turned it off so that they could access fallback content on another site), they end up getting nothing on site 1 and the fallback content on site 2.


4.8.1 The figure element

4.8.2 The img element


  1. Steven's proposal at does a number of nice things. (Recc: adopt this general approach. Rationale is that the user agent and assistive technology support for the elements and attributes in question will be subject to change over time. It's good to have examples, but normative examples are problematic in many of these cases given the state of UA support. Currently, the spec includes roughly 15 pages of alt-related examples, far more extensive than examples provided for any other attribute. Because these concepts apply generally and should apply beyond the scope of the <img> element, the examples should be addressed in a separate section (ex. as an appendix or as part of Regarding the specific examples, a number of them still provide conflicting advice from WCAG 2.0, should be reviewed for consistency with the WAI CG Consensus resolutions and should be updated to reflect ARIA integration when it is complete.
  2. Regarding, "In a conforming document, the absence of the alt attribute indicates that the image is a key part of the content but that a textual replacement for the image was not available when the image was generated." Propose that, as with previous version of HTML, a valid text alternative be present for conformance with the specification. Refer to WAI CG Consensus Resolutions on Text alternatives in HTML 5.
  3. The derivation of caption information in, "If the src attribute is set and the alt attribute is not," ( lists title at the top of the list. Suggest that it instead be listed second, following the first <dt> of the parent <figure>.
  4. The description of text alternatives should include a specific reference to WCAG 2.0 (
  5. This element should include some mechanism to programmatically associate a long description with non-text content (ex. aria-describedby) Requirements for providing text to act as an alternative for images An image in an e-mail or private document intended for a specific person who is known to be able to view images

Ben: Private communication ( should not be listed as an exception. Exceptions of this nature are beyond the scope of both HTML5 and WCAG 2.0 and should be addressed at a policy level rather than the specification level. Guidance for markup generators

AUWG: re alt: Suggest wording be synchronized with "ATAG 2.0 Guideline B.2.4". Specifically: B.2.4.3 Let user agents repair: After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text value that is equally available to user agents (e.g., the filename is not used).

4.8.3 The iframe element

When iframes are processed in keyboard navigation order, the tab order should tab in document order from outside the iframe, into the first focusable item in the iframe, then when it reaches the last focusable item in the iframe, the next tab should exit the iframe and move to the next item in tab order in the parent document. This is because a lot of uses of iframe are to support security in the web page.

Ben: Suggest including advice related to iframe about the use of the title element to identify frames from a navigation perspective. (ex. In speech media, the title attribute provides a label for an iframe, allowing users to more easily navigate to and explore individual sections.)

Gregory: an issue that the <iframe> can't be resized. See

4.8.4 The embed element

Ben: What is the mechanism for providing a short text alternative for embedded content? If there are scenarios where the embedded content itself would be unable to provide a label for the embedded content, the spec should include a mechanism for authors to id the embedded content.  Even if the plugin content has built-in accessibility, the need for fallback content will arise for users on platforms that do not support the plugin, have limited bandwidth, etc.  Propose either dropping this element it in favor of object as proposed in, adding support for fallback content to this element, or adding an attribute that can provide a short text alternative (could be by placing embed inside a figure element with a label, via the alt attribute similar to <img>, aria-labeledby, or via title similar to <iframe>).

4.8.5 The object element


  1. All of the examples provided for object are inside a figure element, which implies that this is the preferred way to use it. Is this the intent?
  2. The algorithm for object specifies that a user agent picks the "first one it supports" -- suggest that this model be revised to allow user agents to identify nested children that may not have been rendered and display them instead. The problem that this addresses is that it allows for situations where the format can be accessible, but often isn't (ex. Flash), allowing users to choose an alternative without having to configure their browsers to render a partilular content type differently depending on the site that they happen to be visiting.

4.8.6 The param element

4.8.7 The video element


  1. Same comments wrt need for short text alternative. Recc. adding support for alt, aria-labeledby and aria-describedby.
  2. One way to think about the need for alt on these elements is that the alt fills the same need as the poster attribute because it " the user an idea of what the video is like."
  3. With regard to the notes on alternative media streams for accessibility, it's not always the case that an appropriate label can be derived from the media itself. Though it would be possible for this information to be extracted by UA via metadata, correct metadata or built-in accessibility will not always be present and may not be something the author can add. Therefore, a mechanism to programmatically assoicate a short and long text alternative should be included in order to ensure that authors are able to provide appropriate short and long text alternatives.
  4. The controls attribute description should require exposing user interface controls for captions and additional audio tracks.

UAWG30: 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.

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.


UAWG31: 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.

4.8.8 The audio element

Ben: <same as for video>

4.8.9 The source element

4.8.10 Media elements Error codes Location of the media resource MIME types Network states Loading the media resource

Ben: for partially usable media data, the specificaion indicates that the UA should "render just the bits it can handle and ignore the rest." What happens if a caption or secondary audio stream fails to load? Suggest that this be revised to require the UA to present an opportunity to load fallback content when it is available. Offsets into the media resource The ready states Cue ranges

Ben: "If the media element's Document stops being a fully active document, then the playback will stop until the document is active again." - This implies that it would not be possible for a user to listen to audio in the background or take notes about a video in another application while viewing the video at the same time. Suggest that the decision about what should be done in this case should be left to the user agent. Playing the media resource Seeking

Ben: Suggest adding the availability of captions or aditional audio tracks to the items listed in a UA provided user interface. "... (e.g. <ins>show captions, turn on audio descriptions, </ins>full-screen video or in an ...)" User interface Time ranges Event summary

Ben: Propose adding additional media events to indicate whether captions and audio descriptions are present, turned on, etc. Security and privacy considerations

4.8.11 The canvas element

Ben: Primary concerns here are that it appears to lack hooks for direct accessibility in a number of places. As with other types of embedded content in this specification, a basic mechanism to include text alternatives (both short and long) is of critical importance. The 2D context Color spaces and color correction Security with canvas elements

4.8.12 The map element

4.8.13 The area element

4.8.14 Image maps Authoring

Ben: Speech browsers and assistive technologies handle text alternatives on image maps and their corresponding area elements differently. Please include a description of the expected behavior for situations where the text alternatives for the individual area elemements may not make sense without the added context of the text alternative for the <img> or <object> that is associated with the <map>. Processing model


  1. Item 8, "For historical reasons, the coordinates must be interpreted relative to the displayed image, even if it stretched using CSS or the image element's width and height attributes." This appears to contradict section 4.8.17, which says, "The dimension attributes are not intended to be used to stretch the image." Is the use of width and height to stretch an image conforming?

4.8.15 MathML

4.8.16 SVG

4.8.17 Dimension attributes

4.9 Tabular data

4.9.1 Introduction

4.9.2 The table element

4.9.3 The caption element

4.9.4 The colgroup element

4.9.5 The col element

4.9.6 The tbody element

4.9.7 The thead element

4.9.8 The tfoot element

4.9.9 The tr element

4.9.10 The td element

4.9.11 The th element

4.9.12 Attributes common to td and th elements

4.9.13 Processing model Forming a table Forming relationships between data cells and header cells

4.10 Forms

UAWG15: 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.

4.10.1 The form element

4.10.2 The fieldset element

4.10.3 The label element

4.10.4 The input element States of the type attribute Date and Time state

UAWG17: 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. Date state

UAWG17: <same as above> Common input element attributes Common input element APIs Common event behaviors

4.10.5 The button element

4.10.6 The select element

4.10.7 The datalist element

4.10.8 The optgroup element

4.10.9 The option element

4.10.10 The textarea element

4.10.11 The keygen element

4.10.12 The output element

4.10.13 Association of controls and forms

4.10.14 Attributes common to form controls Naming form controls Enabling and disabling form controls A form control's value Autofocusing a form control Limiting user input length Form submission

4.10.15 Constraints Definitions Constraint validation

UAWG16: 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. The constraint validation API Security

4.10.16 Form submission Introduction Implicit submission Form submission algorithm URL-encoded form data Multipart form data Plain text form data

4.10.17 Resetting a form

4.10.18 Event dispatch

4.11 Interactive elements

4.11.1 The details element

Cynthia: I’m not sure what this sentence means: 

“The details element represents a disclosure widget from which the user can obtain additional information or controls.”  After reading through the section, it seems to be for those “more info” popups.  There is no discussion of what the default rendering looks like.  I think it looks like this

                <dt>More Info</dt>
                                <p>blah blah blah</p>

Would render as just “More Info”.  The author would have to write script to toggle the “open” attribute.  This should have a built-in tabstop (not specified) and built-in toggling behavior (not specified).  The default rendering should be specified. For example, does an open details section cause the page to reflow? 

Cynthia: Can the <dt> and the <dd> contain any arbitrary tags? 

4.11.2 The command element

Content model is empty.  I think that means it can’t have any tags inside.  Why?  It would be very useful to be able to wrap a command around a larger group of tags.  The Hotmail inbox is a great example of this.  Each message has an icon, a subject, a from field, some time stamps, and a line of text from the message.  The whole thing is clickable, and multi-selectable. 

Attributes:  type, label, icon, disabled, checked, radiogroup.

Title has special semantics, in that it defines a ‘hint’ (which would map to an MSAA description, I think).  This seems like the right general semantic for title.

Type can be normal (which is either a button or a menu item, it’s hard to tell), radio and checkbox.  There’s no markup sample, which makes it confusing why you would use this instead of the <input type=radio|checkbox>.  After reading the whole of 4.11, I think the checkbox state is actually a multi-select state and the radio state is a single-select state.  Having these states outside of a <select> is a good thing.  Radio and checkbox do have those properties, but I think most people think of the rendering more than the selection behavior.  I would change these to @select or @multi-select, and replace @checked with @selected.

Radio buttons can be grouped using the @radiogroup attribute.  The algorithm described seems to require that radiobuttons with the same radiogroup have the same parent.  This is not required of <input type=radio> now, and it’s pretty common for them not to have the same parent.  Why is this required?

Icon and label attributes give the visible and textual representation of the command.  This is actually a really elegant way of handling what is now handled by <a href><img alt="">Display Text</a>.  Label is not currently required, but I think it should be, just like alt.  I would add an attribute that shows or hides the label, so you could have a button that is just an icon, but that has a label anyway.  This would be great for toolbars that shrink and grow based on widow size.  This should also support aria-labeledby and <label for>.  There are situations where text in attributes is problematic in production and localization procedures.  Also, why/how is this label different from aria-label? 

Note:  firing a synthetic click event at the element does not cause any of the actions described above to happen.  WHY?  Synthetic click should always be the same as real click.  This is used by lots of accessibility techniques. 

Command elements are not rendered unless they form a part of a menu.  I don’t think that’s necessary.  The Hotmail inbox example shows a real need for a generic multi-selection mechanism like this, even without a menu.

4.11.3 The bb element Browser button types

4.11.4 The menu element

<menu type=”list|context|toolbar”> (list is default)

I think "list" is a normal popup menu, rather than an always-open menu, but this is a confusing name.  I'd add type=popup which would have the standard open/close menu behavior built in.  I’d make popup the default, rather than list, which would be an always-open menu.  That list could be used for the Hotmail inbox example. 

[as a side note, I find the format really hard to understand.  It talks about processing instructions, and I had to reverse-engineer what the markup would look like]

Working out the API mappings will be interesting here.  This seems to be based on how Mac menus work, where the commands are buttons rather than menu items. Introduction

The example uses a select inside a menu to build a backward-compatible menu (I think that's why it's done).  The rendering of <select> and <option> changes when inside a menu, so <select> is ignored and <option> renders as a command.  This will be tricky for mapping, as the mapping of these elements may change based on context.

The example has a <select> that navigates onchange, which is a WCAG violation.  There is a go button, but it isn't used.   

Both <menu label="Go to…">  and <label for="(id of select)"> are used, and have the same text. This seems goofy and redundant.  Also text in attributes is often a problem for localization.  aria-labeled-by on the select would be a better choice, perhaps?

They also use in the example, <option value="" selected="selected">Select site:</option>.  Which I've always thought of as a worst practice.  This is more feedback for the forms section, but maybe  something like this would interesting

<label>Choose a value</label>

The label would render as the displayed text of the select, and also provide its accessible name, but would not be selectable itself.

[Another side note, the example could perhaps be a little more vendor neutral…] Building menus and tool bars

There is a special case for <option value="" disabled>--------</option>.  Since <hr> is also supported, why is this needed?

Again, processing instructions but no markup.  Why do you need to say "An option element that has a value attribute set to the empty string, and has a disabled attribute, and whose textContent consists of a string of one or more hypens (U+002D HYPHEN-MINUS), rather than the simple markup I used above.

There are way too many ways to define menu items. Context menus

Needs a code sample, but I think they're saying that context menus would work like this:

<menu type="context" id="foo">
<li>Save As…</li>

Then, somewhere else in the DOM

<span contextmenu="foo">  

I think these should only be allowed on tabable elements, or should make the element tabable when they are added.  Similarly, reading order and tabbing order need to be defined in this spec.  We don't want to have to write WCAG techniques that say to put the context menu in the DOM right after the element that triggers it, as that would make them less reusable, or require that every context menu be scripted.

I also wonder if something like this wouldn't be better, but it might be less reusable.

<menu type="context" for="bar">

In the 6th paragraph in this section, it says "The default action of this event is that the user agent must show a context menu built from the menu element.  I'm not sure what this event is or why it's italicized.

The user agent may (I'm assuming this is MAY) also provide access to its default context menu.  I think this should be a MUST, and that there may need to be an attribute that authors can use to say when they don't want that behavior.  Users would need to be able to override the author attribute.

Context menus must not while being shown reflect changes in the DOM… Why?

User agents MAY provide means for bypassing the context menu processing model… This should be a MUST. Tool bars

The user agent MUST reflect changes made to the menu's DOM… why is this the opposite of context menus?

4.11.5 Commands

Again, reverse engineering the markup

<command type="command|radio|checkbox" ID="string" label="string" hint="string" icon="absolute URL of image" accesskey="string" hidden disabled checked action="event handler or URL">

Type=command means a "normal" command.  What is that and how does it behave?  Is that a menu item?  A button?

Why is there a command and an input for radio and checkbox?  Why not use the existing form elements inside the menu?  Select is used this way.

Why only absolute URLS and not relative urls for icons?

Command API (this should have a heading

What elements support this API?  Only those that “define a command”?  Can I use this API on an <option> for example?  If I use this API on a <span>, does it become a command?

Why “facet” and not “attribute”?  How seem to map to the element attributes, so why use a different word?

Does label also return values set with aria-labled-by and aria-label? 

Disabled: This attribute will be shadowed by the disabled IDL attribute on button, input, option, and command elements.  What does that mean?  What does the markup look like? How does the markup map to the API values?  (same feedback for checked)

document.commands:  do <a href>, <button>, <input> etc show up in this collection? Using the a element to define a command

<a href> defines a command (again, written out in longhand as “an a element with an href attribte” why not just use the markup?  It would be both shorter and more clear).  Defines what the type, etc will be.  A table would be more clear, and shorter.

Label is the string given by the elements textContent IDL.  Does this include alt of any images inside the link?

Icon is obtained by resolving the src of the first img in the link.  I like this.

Supports ‘hidden’ but not ‘disabled’.  Why?  I’m guessing because <a href> doesn’t have a disabled state, but why is that? Using the button element to define a command

Button always defines a command.  I like that. Using the input element to define a command

Why do we need this AND <command type=”radio|checkbox”> ?

If the type is command (any input other than type=”radio|checkbox”), then label is given by the value attribute, if any, and a UA-dependent, locale-dependent value that the UA uses to label the button itself if the attribute is absent.  HUH? What does that mean?  Examples, please?  What about <label for>, aria-label, aria-labeled-by?  Also, in IE, title fills in the accname if none of this other stuff does.  Should it?

Image button has an icon, others don’t.  Why not use the first image inside a button or label, like what is done for <a href> Using the option element to define a command

An option element with an ancestor select element and either no value attribute or a value attribute that is not the empty string defines a command.  So… <option value=””> is not a command, but <option value=”foo”> and <option> with no value is?  Why is <option> with no value allowed? 

The type of the command is “radio” if the options nearest ancestor select element has no multiple attribute, and checkbox if it does.  So…

<select multiple>

Defines a bunch of checkboxes, and

<select multiple>

Defines a bunch of radio buttons.

Is this only true if it’s inside a menu?  Should these be commands when they’re not in a menu?  There are issues with select being used as a menu. 

Should these be mapped to button or menu item?

How does this render?  Does it render with actual radio and checkbox UI?  If not, should commands be <command type=”action|single-select|multiple-select”> instead of radio/checkbox? Using the command element to define a command

Why is this in a separate section from the command element? Using the bb element to define a command Using the accesskey attribute on a label element to define a command Using the accesskey attribute on a legend element to define a command Using the accesskey attribute to define a command on other elements

Lachlan says accesskey on the <command> element provides nearly all the features of the XHTML access module. What's missing is role-based navigation. See Rich's access key requirements. We need to decide if we think what HTML has goes far enough, and if not make specific suggestions for what change needs to be made.

4.12 Miscellaneous elements

4.12.1 The legend element

4.12.2 The div element

4.13 Matching HTML elements using selectors


  1. It's unclear how :active would apply to <link>. Are there cases where the link element would be specifically focusable in HTML5?
  2. How will selectors interact with WAI-ARIA? For example, will :checked apply to the following?
    <li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>
    Please include an explanation that describes this interaction and include additional bullet items for applicable selectors (ex. for :checked, any other element that has an aria-checked state).

5 Microdata

5.1 Introduction

5.1.1 The basic syntax

5.1.2 Typed items

5.1.3 Selecting names when defining vocabularies

5.1.4 Using the microdata DOM API

5.2 Encoding microdata

5.2.1 The microdata model

5.2.2 Items: the item attribute

5.2.3 Associating names with items

5.2.4 Names: the itemprop attribute

5.2.5 Values

5.3 Microdata DOM API

5.4 Predefined vocabularies

5.4.1 General

5.4.2 vCard Examples

5.4.3 vEvent Examples

5.4.4 Licensing works Examples

5.5 Converting HTML to other formats

5.5.1 JSON

5.5.2 RDF

5.5.3 vCard

5.5.4 iCalendar

5.5.5 Atom

6 Web browsers

6.1 Browsing contexts

6.1.1 Nested browsing contexts Navigating nested browsing contexts in the DOM

6.1.2 Auxiliary browsing contexts Navigating auxiliary browsing contexts in the DOM

6.1.3 Secondary browsing contexts

6.1.4 Security

6.1.5 Groupings of browsing contexts

6.1.6 Browsing context names

6.2 The WindowProxy object

6.3 The Window object

6.3.1 Security

6.3.2 APIs for creating and navigating browsing contexts by name

6.3.3 Accessing other browsing contexts

6.3.4 Named access on the Window object

6.3.5 Garbage collection and browsing contexts

6.3.6 Browser interface elements

6.4 Origin

6.4.1 Relaxing the same-origin restriction

6.5 Scripting

6.5.1 Introduction

6.5.2 Enabling and disabling scripting

6.5.3 Processing model Definitions Calling scripts Creating scripts Killing scripts

6.5.4 Event loops Definitions Processing model Generic task sources

6.5.5 The javascript: protocol

6.5.6 Events Event handler attributes Event handler attributes on elements, Document objects, and Window objects Event firing Events and the Window object Runtime script errors

6.6 Timers

6.7 User prompts

6.7.1 Simple dialogs

6.7.2 Printing

6.7.3 Dialogs implemented using separate documents

6.8 System state and capabilities

6.8.1 Client identification

6.8.2 Custom scheme and content handlers Security and privacy Sample user interface

6.8.3 Manually releasing the storage mutex

6.9 Offline Web applications

6.9.1 Introduction Event summary

6.9.2 Application caches

6.9.3 The cache manifest syntax A sample manifest Writing cache manifests Parsing cache manifests

6.9.4 Updating an application cache

6.9.5 Matching a fallback namespace

6.9.6 The application cache selection algorithm

6.9.7 Changes to the networking model

6.9.8 Expiring application caches

6.9.9 Application cache API

6.9.10 Browser state

6.10 Session history and navigation

6.10.1 The session history of browsing contexts

6.10.2 The History interface

6.10.3 Activating state object entries

6.10.4 The Location interface Security

6.10.5 Implementation notes for session history

6.11 Browsing the Web

6.11.1 Navigating across documents

6.11.2 Page load processing model for HTML files

6.11.3 Page load processing model for XML files

6.11.4 Page load processing model for text files

6.11.5 Page load processing model for images

6.11.6 Page load processing model for content that uses plugins

6.11.7 Page load processing model for inline content that doesn't have a DOM

6.11.8 Navigating to a fragment identifier

6.11.9 History traversal

6.11.10 Unloading documents Event definition

6.12 Links

6.12.1 Hyperlink elements

6.12.2 Following hyperlinks

Sally: "...the user agent may report the error to the user in a user-agent-specific manner, may navigate to an error page to report the error, or may ignore the error and do nothing." If unable to resolve URI, UA has option of doing nothing. The user should get an error message that is accessible and understandable.

Sally: "...if these rules result in the creation of a new browsing context, it must be navigated with replacement enabled." A general issue around 'browsing contexts' and ensuring accessibility of these 'views'. There may be an instance where a second browsing context is presented to the user. It should be accessible to the user and presented consistently.

Sally: "Otherwise, if the hyperlink element is a sidebar hyperlink and the user agent implements a feature that can be considered a secondary browsing context, such a secondary browsing context may be selected as the browsing context to be navigated." I'm honestly a bit confused by the concept of 'secondary browsing context' and 'sidebar hyperlink', but I believe this could mean that the urls will open in a part of the user agent's interface, which is not the main content area. Then this should be made clear to users. Hyperlink auditing

Sally: explanation of ping attribute at end of section Generally this attribute looks to improve things but there is one statement: "It allows the paranoid user to disable the notifications without losing the underlying link functionality." Can we ensure that the notifications are accessible in the first instance, and then that the way to switch them off is accessible?

6.12.3 Link types

Sally: This is attempting to encapsulate more meaningful links but I am not clear generally how is this information presented to the user and screen reader? There are a lot of these listed in this section. One still on the WHATWG wiki is rel=accessibility which is just a proposal at present. Link type "alternate" Link type "archives" Link type "author" Link type "bookmark" Link type "external" Link type "feed" Link type "help"

Sally: The example suggests to have the 'help' link following the relevant form element. This goes against what we RNIB always recommend, which is to have the help link between label and field, but *NOT* part of the label element. Link type "icon"

Sally: The spec states "Icons could be auditory icons, visual icons, or other kinds of icons". But are 'auditory icons' meant to be played by the AU as soon as a page loads? This may clash with AT such as screen readers especially if the audio sample is long. Link type "license"

Sally: Spec does not specify how to distinguish between main content of the doc and the rest. Surely this should be clear and there should be a way to distinguish. If nothing else so people jumping around content using shortcuts are clear what they are reading.

Sally: This example uses an old technique RNIB advise against, which is a printable character '|' between links. This was a AAA in WCAG 1.0 but fortunately disappeared from WCAG 2.0. CSS or a decorative image with empty ALT="" would be preferred.

JamesC: The paragraph after the HTML example code states, "In this case, the license applies to just the photo, not the whole document." However, the example is not marked up in a way that can be determined by assistive technology. If license is meant to apply to anything other than the entire document, the specification should define rules to make the relationship determinable by assistive technology. Link type "nofollow"

Sally: "The nofollow keyword indicates that the link is not endorsed by the original author or publisher of the page, or that the link to the referenced document was included primarily because of a commercial relationship between people affiliated with the two pages." This could be a bit of information that could be worth to have *all* user agents to pass on to users, including screen readers. Link type "noreferrer" Link type "pingback" Link type "prefetch" Link type "search" Link type "stylesheet" Link type "sidebar"

Sally: This links back to my comment on secondary browsing contexts and ensuring accessibility above. Anything that is going to open somewhere other than the main content area needs to be made clear to users. Link type "tag"

JamesC: Link type "tag" specifies the link relationship, but does not specify how the tag name is to be determined apart from the link's text equivalent. The specification does not define how an author might differentiate hyperlinks referring to the same tag in different scopes. For example, on Flickr, there are two links for each tag: "your photos with tag: 'foo'" and "others' photos with tag: 'foo'"… If the text equivalent for both links the same, an assistive technology user will not be able to perceive the difference. If the text is different, there is no machine-readable way for a script to understand that both links refer to the same tag. The Microformats wiki page for rel-tag attempts to solve this problem by enforcing a RESTful tag URL apart from the text equivalent, but it still has several unaddressed development and internationalization issues. <> If this type of link relationship is to remain, consider adding an optional data attribute to allow the author to explicitly state the tag name if it is not the same as the text equivalent. Hierarchical link types

Sally: This way of structuring documents and the relationships between them needs to be clear and be understood by the screen reader user as having relationships. Link type "up"

JamesC: The example code uses a related set of links to define the breadcrumb navigation, but does not use a list element, so there is no way for assistive technology to convey the hierarchy or relationship between the links. The example should probably group the links in a list element, and should also provide some sort of text equivalent to explain the purpose of each list and convey the difference between the two types of breadcrumb lists. Sequential link types

Sally: Again this way of structuring documents and the relationships between them needs to be clear to the screen reader user. Other link types

Sally: What I am not clear about is how/when other link types will be approved. It does state in the spec at the moment that this is not clear yet. When the spec is published will people be able to continue to propose to the WHATWG Wiki new types that get accepted? Could this mean a rash of new types which just keep getting accepted without being formally approved?

7 User Interaction

7.1 Introduction

7.2 The hidden attribute

UAWG05: 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.

UAWG12: 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

7.3 Activation

7.4 Scrolling elements into view

UAWG06: 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.

UAWG13: 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.

7.5 Focus

7.5.1 Sequential focus navigation

7.5.2 Focus management

7.5.3 Document-level focus APIs

UAWG07: 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.

7.5.4 Element-level focus APIs

7.6 The accesskey attribute

@@need for full Access Module functionality

UAWG18, UAWG19: So looking at this further, I see that in 7.6 list-item 2 @@can't find@@ 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 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?

7.7 The text selection APIs

7.7.1 APIs for the browsing context selection

7.7.2 APIs for the text field selections

7.8 The contenteditable attribute

UAWG08: 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.)

UAWG09: 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. )

7.8.1 User editing actions

7.8.2 Making entire documents editable

7.9 Spelling and grammar checking

7.10 Drag and drop

UAWG10: 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

UAWG14: 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.

7.10.1 Introduction

7.10.2 The DragEvent and DataTransfer interfaces

7.10.3 Events fired during a drag-and-drop action

7.10.4 Drag-and-drop processing model When the drag-and-drop operation starts or ends in another document When the drag-and-drop operation starts or ends in another application

7.10.5 The draggable attribute

UAWG20: 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?

7.10.6 Copy and paste Copy to clipboard Cut to clipboard Paste from clipboard Paste from selection

7.10.7 Security risks in the drag-and-drop model

7.11 Undo history

UAWG11: This should include drag and drop

7.11.1 Introduction

7.11.2 Definitions

7.11.3 The UndoManager interface

7.11.4 Undo: moving back in the undo transaction history

7.11.5 Redo: moving forward in the undo transaction history

7.11.6 The UndoManagerEvent interface and the undo and redo events

7.11.7 Implementation notes

7.12 Editing APIs

8 Communication

8.1 Event definitions

8.2 Cross-document messaging

8.2.1 Introduction

8.2.2 Security Authors User agents

8.2.3 Posting messages

8.2.4 Posting messages with message ports

8.3 Channel messaging

8.3.1 Introduction

8.3.2 Message channels

8.3.3 Message ports Ports and garbage collection

9 The HTML syntax

Sally: It appears that the main change here is that they have changed the way the syntax works moving away from SGML. I don't know enough about this to comment if it does have an impact on accessibility. The doctype ensures the page renders in standards mode which is a good thing and seems to be supported by most browsers already.

9.1 Writing HTML documents

9.1.1 The DOCTYPE

9.1.2 Elements Start tags End tags Attributes Optional tags Restrictions on content models Restrictions on the contents of raw text and RCDATA elements

9.1.3 Text Newlines

9.1.4 Character references

9.1.5 CDATA sections


9.2 Parsing HTML documents

9.2.1 Overview of the parsing model

9.2.2 The input stream Determining the character encoding

Sally: Nothing in WCAG 2.0 mentions any requirements for charset. However, because of RNIB's experience with See it Right and some browsers - specifically Internet Explorer 6 - We wanted to include in Surf Right a checkpoint for valid charsets. We never checked on other versions of Internet Explorer, but on IE6, if you don't specify a charset, some characters are not correctly displayed and replaced by things like French letters or other symbols. So we don't need to be too strong about it in the HTML5 document. It would be nice though, to have a note saying that to ensure compatibility with older UA having a charset would be advisable. Preprocessing the input stream Changing the encoding while parsing

9.2.3 Parse state The insertion mode The stack of open elements The list of active formatting elements The element pointers Other parsing state flags

9.2.4 Tokenization Data state Character reference data state Tag open state Close tag open state Tag name state Before attribute name state Attribute name state After attribute name state Before attribute value state Attribute value (double-quoted) state Attribute value (single-quoted) state Attribute value (unquoted) state Character reference in attribute value state After attribute value (quoted) state Self-closing start tag state Bogus comment state Markup declaration open state Comment start state Comment start dash state Comment state Comment end dash state Comment end state Comment end bang state Comment end space state DOCTYPE state Before DOCTYPE name state DOCTYPE name state After DOCTYPE name state Before DOCTYPE public identifier state DOCTYPE public identifier (double-quoted) state DOCTYPE public identifier (single-quoted) state After DOCTYPE public identifier state Before DOCTYPE system identifier state DOCTYPE system identifier (double-quoted) state DOCTYPE system identifier (single-quoted) state After DOCTYPE system identifier state Bogus DOCTYPE state CDATA section state Tokenizing character references

9.2.5 Tree construction Creating and inserting elements Closing elements that have implied end tags Foster parenting The "initial" insertion mode The "before html" insertion mode The "before head" insertion mode The "in head" insertion mode The "in head noscript" insertion mode The "after head" insertion mode The "in body" insertion mode The "in RAWTEXT/RCDATA" insertion mode The "in table" insertion mode The "in table text" insertion mode The "in caption" insertion mode The "in column group" insertion mode The "in table body" insertion mode The "in row" insertion mode The "in cell" insertion mode The "in select" insertion mode The "in select in table" insertion mode The "in foreign content" insertion mode The "after body" insertion mode The "in frameset" insertion mode The "after frameset" insertion mode The "after after body" insertion mode The "after after frameset" insertion mode

9.2.6 The end

9.2.7 Coercing an HTML DOM into an infoset

9.2.8 An introduction to error handling and strange cases in the parser Misnested tags: <b><i></b></i> Misnested tags: <b><p></b></p> Unexpected markup in tables Scripts that modify the page as it is being parsed

9.3 Namespaces

9.4 Serializing HTML fragments

9.5 Parsing HTML fragments

9.6 Named character references

10 The XHTML syntax

10.1 Writing XHTML documents

10.2 Parsing XHTML documents

10.3 Serializing XHTML fragments

10.4 Parsing XHTML fragments

11 Rendering

11.1 Introduction

11.2 The CSS user agent style sheet and presentational hints

11.2.1 Introduction

11.2.2 Display types

11.2.3 Margins and padding

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

11.2.4 Alignment

11.2.5 Fonts and colors

UAWG28: 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.

11.2.6 Punctuation and decorations

11.2.7 Resetting rules for inherited properties

11.2.8 The hr element

11.2.9 The fieldset element

11.3 Replaced elements

11.3.1 Embedded content

11.3.2 Images

11.3.3 Attributes for embedded content and images

11.3.4 Image maps

11.3.5 Tool bars

11.4 Bindings

11.4.1 Introduction

11.4.2 The bb element

11.4.3 The button element

11.4.4 The details element

11.4.5 The input element as a text entry widget

11.4.6 The input element as domain-specific widgets

11.4.7 The input element as a range control

11.4.8 The input element as a color well

11.4.9 The input element as a check box and radio button widgets

11.4.10 The input element as a file upload control

11.4.11 The input element as a button

11.4.12 The marquee element

11.4.13 The meter element

11.4.14 The progress element

11.4.15 The select element

11.4.16 The textarea element

11.4.17 The keygen element

11.4.18 The time element

11.5 Frames and framesets

11.6 Interactive media

11.6.1 Links, forms, and navigation

11.6.2 The mark element

11.6.3 The title attribute

11.6.4 Editing hosts

11.7 Print media

11.8 Interaction with CSS

11.8.1 Selectors

12 Obsolete features

12.1 Obsolete but conforming features

12.1.1 Warnings for obsolete but conforming features

12.2 Non-conforming features


abbr attribute shouldn't be removed, it has a valid use case? Use the language from HTML 4 about how to use it still.

Maybe instead we need the opposite use case: way to provide an expanded version.

@@need to discuss more

12.3 Requirements for implementations


Unsure what the well defined elements are here. Not sure if it's an accessibility issue.

12.3.1 The applet element

12.3.2 The marquee element


Marquee should default to off.

@@this needs more review

12.3.3 Frames

12.3.4 Other elements, attributes and APIs

13 Things that you can't do with this specification because they are better handled using other technologies that are further described herein

13.1 Localization

13.2 Declarative 3D scenes

IANA considerations

13.1 text/html

13.2 application/xhtml+xml

13.3 text/cache-manifest

13.4 application/microdata+json




Additional feedback

Suggest a section on tabbing describing tab cycle, default tabbable elements, use of tabindex=-1, what happens with special elements like iframe

Sally: What do we know of the roadmap for screen reader vendors to support html5?


  1. In some sections of the spec, a lack of code examples (especially for new elements and attributes) makes it difficult to envision exactly how some features might work in practice. Please consider including additional examples where possible.
  2. When WAI-ARIA is integrated into the specification, much of this review will need to be revisisted. For example, whether the removal of ARIA attributes will render content nonconforming will be a key factor.
  3. The inclusion of an appendix similar to SVG Appendix H: Accessibility Support ( may help address accessibility issues that span multiple sections of HTML5 .
  4. The HTML5 concept requiring validity for conformance seems to be a barrier to progress in certain areas. For example, the assumption that an author should be able to create valid code by creating a new file, dragging an image into the file within an editor, saving and closing should yield valid, cofrming code, does not promote awareness of accessibility or adequately address the needs of individuals with disabilities.
  5. The spec has not yet fully incorporated the reccs in and we encourage the WG to continue its efforts to include them.
  6. Please consider using the term "text alternative" rather than "text equivalent." This phrase is more consistent with the @alt attribute name, with current WAI recommendations,  and the fact that alternatives to non text content are rarely true equivalents.

UAWG01: massive document, changing frequently. HTML so complex, and nuanced, concerns about missing accessibility issues

UAWG02: Fallback content - no user agent provides a mechanism to retrieve author created fallback content: Embedded content - definition of fallback content; 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)

UAWG04: 3.2.6 Annotations for assistive technology products - are these in sync with ARIA (MC: can't find section)

UAWG25: 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?

UAWG26: I've not seen a good definition of quirks or limited- quirks modes.

UAWG27: 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.

Authoring Tools and Markup Generators

AUWG: "Authoring tools are exempt from the strict requirements of using elements only for their specified purpose, but only to the extent that authoring tools are not yet able to determine author intent." Suggest stating that authoring tools should help authors meet the strict requirement (of using elements only for their specified purpose) by not automatically misusing elements or encouraging the author to do so (e.g. in documentation)

AUWG: "Authoring tools are expected to come in two broad varieties: tools that work from structure or semantic data, and tools that work on a What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG). The former is the preferred mechanism for tools that author HTML, since the structure in the source information can be used to make informed choices regarding which HTML elements and attributes are most appropriate." It seems subjective to prefer an editing mechanism. Perhaps this should be clearly marked as "informative".

AUWG: "However, WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are appropriate, and should not use elements that they do not know to be appropriate. This might in certain extreme cases mean limiting the use of flow elements to just a few elements, like div, b, i, and span and making liberal use of the style attribute." Suggest stating that WYSIWYG tools may need to make a special effort to gather semantic information, rather than describing exceptions for "extreme cases".