Over the past month I have been participating in the HTML Accessibility Task Force, a joint task force of the Protocols and Formats Working Group (PFWG) and the HTML Working Group (HTML WG) of the W3C. I thought I'd take a moment to share some of what I have been working on thus far.

Drag and drop

During the first task force conference call that I participated in Gez Lemon (@gezlemon) spoke about issues regarding the HTML5 Drag and Drop API. After the call I contacted Gez and asked how I could help.

One of the major questions needing to be answered by the task force was whether any changes were required to the specification to ensure that drag and drop could be made accessible to, amongst others, keyboard only and screen-reader users. After reading through the specification I wrote Proposal for html5 drag and drop keyboard accessibility workflow. The proposal was discussed during a subsequent call, which resulted in Gez filing two bugs.

The first bug, Bug 10712 – Drag and Drop: Add an attribute to identify drop targets, was filed to ensure that user agents and assistive technologies will have the necessary semantics to be able to enumerate the list of drop targets within a document. HTML5 already specifies a "draggable" attribute, so enumerating, or otherwise exposing, draggable elements within the document will not be a problem.

The second bug, Bug 10713 – Drag and Drop: Add guidance for keyboard-only interaction is simply requesting changes to the text of the specification, to ensure that it is input device agnostic, or at least that wherever pointing device actions are mentioned, that a keyboard alternative is also mentioned.

Video poster alternative text

One of the more exciting new elements specified in HTML5 is the video element. The video element allows authors to embed video content into their documents without relying on browser plugins to play the video. One of the attributes of the video element is poster.

The poster attribute gives the address of an image file that the user agent can show while no video data is available. (http://dev.w3.org/html5/spec/video.html#attr-video-poster)

Although an author can specify an image to be displayed visually to users through the poster attribute, there is currently no mechanism through which authors can specify an alternate textual representation of the poster image. Recognizing this as a violation of WCAG 2.0, I filed a bug: Bug 10642 – No alternative text description for video key frame (poster).

Modal dialogs

Back in March I wrote an article, Can a modal dialog be made to work properly for screen-reader users on the web?, to which the answer is" yes, sometimes, with a great deal of effort. Within Drupal 7 we have been working to make the Overlay module, which implements modal behavior, accessible, while at the same time not introducing barriers for users without the latest browsers and assistive technologies. Recognizing that implementing modal behavior within web applications is tricky, and that making it accessible is even trickier, I filed a bug to add modal behavior to the HTML5 specification: Bug 10645 – Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog).

Tablists and tabs as menus

Along with the new video element, HTML5 specifies menu and command elements. Using menu and command together the specification currently provides authors with the ability to implement standard menus, context menus, and toolbars for their web applications. Recognizing that tablists (a collection of tabs used to expose a single view within a user interface) are popular within desktop applications and on the web, I filed a bug to request that new states be added to these elements to support tablist behavior: Bug 10831 – Provide tablist and tab states for menu and command elements respectively

Tooltips and the title attribute

In most, if not all, desktop browsers, the title attribute on an element is rendered as a tooltip. These tooltips are rarely accessible. It is seldom that the content of the tooltip can be resized, restyled, or accessed by keyboard. On mobile devices the content of the title attribute is also rarely accessible. HTML5 does not attempt to tell user agents precisely how to render user interfaces, so this is a tricky issue to address in HTML5 alone. Nevertheless, to get the issue out there, and to generate discussion, I filed a bug: Bug 10873 – Provide a method of explicitly setting a tooltip for an element