Thoughts on the HTML 5 Working Draft

  • 0
  •  0

Written by: Jonathan Avila

The last call for comments on the working draft of the HTML 5 specification has been made and comments are due by today. Over the past several years things have been added, removed, and changed in the specification and sometimes it appeared that HTML 5 would never get out of the draft stage. Since the undertaking began technology has dramatically changed and other accessibility related documents have been released including the Web Accessibility Initiatives’ (WAI) Accessibility Rich Internet Applications (ARIA) specification as well as the Web Content Accessibility Guidelines (WCAG) version 2.0. At points there were concerns that HTML 5 would not contain certain markup that was used for data table accessibility and might change how alt attributes were applied to elements. Now that things have settled more I thought it useful to share some noteworthy observations from my review of HTML 5.

The HTML 5 specification encourages developers and conformance checkers to use appropriate HTML elements instead of ARIA based equivalents. In general this is a good practice to ensure the most accessibility across user agents and platforms. HTML 5 includes more structural elements for sections of a document and a broader range of input element types that will assist developers in using HTML markup. However there are still many aspects of the ARIA specification that are not addressed in HTML 5 such as live regions and the ability to provides roles such as presentation and img to allow assistive technologies such as screen readers to treat enclosing content differently when a more appropriate HTML element does not exist.

Section Related Elements

There are number of new elements that have been added that will assist in creating more structure to web based documents and applications. These include:

nav
The nav element is intended to group navigation links and will facilitate assistive technology in allowing the user to jump past repetitive links as well as display links in lists that are grouped.
section
The

element is a block of content within a page that generally should contain a heading element within it. Use of this element will allow better sectioning of page content rather than just assuming that sections end when another heading of the same level appears. This will allow assistive technology such as software for people with cognitive impairments to only display the current section of the document and will allow screen reader users to read content by section.
article
The Article element is more specific version of the section element that is independent content on the page. The article element should be used for articles such as news articles, posts, blog posts, or other independent content that could stand alone.
header
The header element is designed to contain header information for a section, article, etc. and contains the heading for that section. It does not start a new section by itself but is used to group header content. Information in header element could be used by screen readers to form summaries of the sections of the page for users. This is distinctly different from the ARIA landmark role of banner which is designed to be a header section for the entire document.
footer
Like the header element, the footer element is designed to be used within sections of the document to provide footer information for that section such as author information, citations, links, etc. for a given article or section. A document can contain multiple footer elements. This is distinctly different than the ARIA landmark role of contentinfo which is designed to be a footer for the entire document.

Note: Other elements such as the details element and child summary element were also added to provide additional details that are collapsed by default for a section or document.

Images

The longdesc attribute has been removed in favor of developers providing an on-screen link to additional descriptions for complex images, charts, and graphs that cannot be accurately described using the alt attribute. This is a good improvement as the logndesc attribute was often not visible or accessible to users who were not using a screen reader. We generally encourage developers to also include on-screen text describing the chart or image on the same screen where practical.

The HTML 5 documents indicate that if alt text is not known for an image that it can be left out. Furthermore the documents indicate that conformance checkers can consider a document conformant if an image contains a title attribute and no alt attribute. This is worrisome as the HTML 5 specification also states that the title attribute is advisory only and does not represent a replacement for the image. Assistive technology users such as screen reader users rely on the alt attribute to provide a replacement for the image. The consistent use of the alt attribute on images must be maintained.

The HTML specification has always held that the alt attribute is a replacement for an image and should NOT be displayed by user agents (browsers) unless images are turned off or not available. This premise is challenging for users with low vision who likely are not using a screen reader but can see most images and have images turned on in the user agent to have the same access to visual content as users without a visual impairment. The alt attribute however is thus not available to low vision users who may be able to perceive most but not all image meaning. The authors of the HTML 5 specification must consider the needs of users with low vision in having access to the programmatic alt attribute for images in which normal vision is required to perceive the function of the image.

The new figure and figcaption elements are discussed later in this post.

Data Tables

The one primary change related to data table accessibility is the removal of the scope attribute on the td element. In the past it was common for developers to use the scope attribute on the td element to indicate row headers. The scope attribute is still available on the th element and thus th would need to be used for table row headers. Like prior specifications, both td and th allow for the headers attribute for complex data table association.

The specification provides non-normative guidance on data table detection based on the border attribute. If the border attribute is set to “1” the table is likely a data table. If the border attribute is set to “” then the table is likely a layout table. The border attribute can have no other value in HTML 5. This in conjunction with the ARIA role of presentation provides automatic accessibility testing tools and assistive technologies some valuable information (when implemented) to the purpose of a given table.

Other New and Redesigned Elements

Menu

There are a number of other new elements such as the redesigned menu element. The menu element is not currently supported by major browsers and its ability to contain many different types of element including anchors (a), list items, button, select and command elements may produce challenges for assistive technologies. Menus can also be presented as type list, context menu, or toolbar with different potential navigation methods for users of assistive technology.

Input

There are many new type attributes for the input element. New types of input elements include a calendar, and color picker. These potentially pose accessibility related challenges in how they are implemented in different user agents. The API level recommendations for controls such as the color picker provided in the HTML 5 supporting document do not specifically call out accessibility support including access via the keyboard.

One new type attribute of the input field is number. This in conjunction with the possible use of the pattern attribute (which is designed for validation) could be used to automatically turn on-screen keyboards like the iPhone’s into the numeric keyboard when entering an input field.

The new required attribute on input fields can be very useful to users of assistive technology and to automatic testing tools. However, the use of this attribute may not guarantee access to that information for all users. For example, some user agents may indicate a visual change for this attribute by showing that the field is required when the user hovers over the field. This implementation, however, may not be accessible via the keyboard. It seems that while knowing this programmatically is very useful for validation and for usability this information must still be visually available to all users. Developers must be instructed that programmatic indication is not a reason to removal visual indication of required fields and constraints.

The new autofocus attribute on input fields sounds very useful although some users of assistive technology may want to turn it off. It instructs the user agent to set focus to that field upon document load. This can only be set on a single field per document.

It appears that no explicit default button implementation was accepted into the current draft for HTML forms. The draft document discusses implied functionality depending on the platform being used but this is and has been inconsistent across browsers and platforms.

Figure and Figcaption

The figure and figcaption elements are designed to be used together to markup figures and other complex images with onscreen captions. This will hopefully provide on-screen descriptions rather than developers relying on the alt and title attributes for providing image equivalents and advisory information.

Canvas

Currently content in the canvas element is not accessible. The HTML 5 draft specification (August 3, 2011) indicates:

When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.

The use of fallback content is unfortunately required because there is no defined standardized accessibility implementation for canvas content. Separate access is not equal access and while some equivalent content may be usable to some users of assistive technology it will not be accessible to all users with disabilities.

Specifically, fallback content that appears inside the canvas element but not on-screen poses serious issues for users with low vision. Visual focus of off-screen elements is an issue for users of screen magnification and low vision users who use the keyboard. The result is no visual keyboard indication of the fallback content no tracking of programmatic focus for the fallback content in the magnified area. An accessibility implementation and API for canvas accessibility must be developed and supported by user agents. Thus, the canvas is less accessible than Flash at the moment and the proposed alternatives in HTML are not acceptable to users.

Audio and Video

The audio and video elements provide for playback of a range of audio and video content. Developers can supply custom user interfaces or opt to default to the user agent to supply a user interface for the audio or video element. The degree of accessibility varies in the user agent generated elements. One aspect of the video element is that it appears to be missing an accessibility equivalent is the poster image for the video. There does not appear to be an attribute such as the alt attribute to supply alternative text to the poster frame image.

Anchor and Area Element Changes

Anchor elements without href attributes are not deemed supported and are designed to be treated as a link that is a placeholder only. Traditionally, developers used named anchors with href attribute as an anchor for skip navigation links. This poses a change in how many traditional skip navigation links are created. Instead traditional skip navigation links would need to reference other named element such as link with href, div, heading, etc. The reference can also be used to map to elements with a specific id but support is not available in all user agents. In the past different user agents did not always support moving focus to named anchors and named elements the same. For instance, visual focus should move and programmatic focus should be moved so after the user activates the skip link and the user presses the tab key focus goes to the next link after the named element and not back to the element after the skip navigation link.

In regards to area links, the specification indicates that area elements with duplicative actions need not have meaningful alt text. These element would appear to be in the tab order and thus when encountered via a screen reader would produce unexpected results as there would be no valid alt text to announce.

Ensuring Visual Focus

There is some discussion in the HTML 5 documents discussing the importance of visual focus. The document describes but cautions against turning off visual focus provided by the user agent using CSS. Visual focus is very important to users of the keyboard and to users with low vision. More emphases must be placed on ensuring visual focus for all interactive elements. This includes how developers set focus and how HTML APIs instruct user agents to expose visual focus for user agent rendered controls such as video, canvas, audio, calendar, color picker, etc.

Conclusion

There are many new and redesigned aspects of the HTML 5 that promote accessibility in web based documents. However, the effort must continue to ensure that all content can be made accessible to users at the level of the specification. For instance, guidelines such as the WCAG version 2.0 cannot be fully implemented for canvas content. Furthermore, more instructions in the API sections of the HTML 5 documentation must be included to support access to content via the keyboard. It has been 14 years since the last major update of the HTML specification (version 4.0) and the new specification is much needed to provide consistency and increased structure to the web.

No Comments

    Leave A Comment