The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Considering accessibility

Tuesday, January 21st, 2020

Sometimes, new authors need a gentle reminder to think about accessibility when designing and writing web pages and apps. Experienced authors need a quick way to look up the allowed ARIA roles, states and properties for each HTML element. Browser and Assistive Technology (AT) implementers need quick access from an HTML element to its platform accessibility API.

For a look at how these needs translated into the new Accessibility considerations section for each element, please see "POURing ARIA into the HTML element specs" over at 24 Accessibility.

Posted in Elements | Comments Off on Considering accessibility

This Week in HTML5 – Episode 36

Sunday, September 27th, 2009

Since I started publishing these weekly summaries over a year ago, I've watched the HTML5 specification grow up. In episode 1, the big news of the week was the birth of an entirely new specification (Web Workers). Slowly, steadily, and sometimes painstakingly, the HTML5 specification has matured to the point where the hottest topic last week was the removal of a little-used element (<dialog>) and the struggle to find a suitable replacement for marking up conversations.

This week's changes are mundane, and I expect (and hope!) that future summaries will be even more mundane. That's a good thing; it tells me that, as implementors continue implementing and authors continue authoring, there are no show-stoppers and fewer and fewer "gotchas" to trip them up. Thus, the overarching theme this week -- and I use the term "theme" very loosely -- is "the never-ending struggle to get the details right."

Parsing

HTML5 is full of algorithms. Most of them are small parts of one mega-algorithm, called Parsing HTML Documents. Contrary to popular belief, the HTML parsing algorithm is deterministic: for any sequence of bytes, there is one (and only one) "correct" way to interpret it as HTML. Notice I said "any sequence of bytes," not just "any sequence of bytes that conforms to a specific DTD or schema." This is intentional; HTML5 not only defines what constitutes "valid" HTML markup (for the benefit of conformance checkers), it also defines how to parse "invalid" markup (for the benefit of browsers and other HTML consumers that take existing web content as input). And sweet honey on a stick, there sure is a lot of invalid markup out there.

Accessibility

As with so many things in the accessibility world, all of this week's changes revolve around the thorny problem of focus. I previously explained why focus is so important in episode 24.

Security

All of this week's security-related changes revolve around document.domain. As you might expect from its name, this property returns the domain name of the current document. Unfortunately (for security), the property is not read-only; you can also set document.domain to pretty much anything. This can cause all sorts of horrible side effects, since so many things (cookies, local storage, same-origin restrictions on XMLHttpRequest) rely on the domain of the document. This set of changes attempts to reduce the nasty side effects (and the possible attack surface) in case you absolutely must set document.domain to something other than its default calcuated value.

Semantics

Video

As regular readers of this column are aware, one of the big new user-visible features of HTML5 is native video support without plugins. As video is incredibly complicated, so to is the video support in HTML5. (Although not related to this week's changes, you may be interested to read my series, A gentle introduction to video encoding.)

Web Forms

Forms continue to be difficult.

Interesting Discussion Threads This Week

Around the Web

Tune in next week for another exciting edition of "This Week in HTML5."

Posted in Weekly Review | 1 Comment »

Quality Assurance tools for HTML5

Sunday, July 19th, 2009

I see more and more people switch over to HTML5 these days, and to help you make sure you did things correctly, there are some tools at your disposal that might be good to know about.

HTML5 validator

To make sure you didn't misspell any tag or nest elements in a way that is not allowed, or find similar mistakes in your markup, you can use Validator.nu.

Alt text for images

The above-mentioned validator has a feature to help you quality-check your alternative text for your img elements. Check the Show Image Report checkbox.

You can also disable images in your browser or try to use a text-only browser — the information that the images convey should still be available (but in text form). Sometimes an image doesn't convey any further information than what the surrounding text already says, and in such cases you should use the empty value: alt="".

For further advice and examples on how to use the alt attribute, the HTML 5 spec has lots of information on the topic. If you're not going to read it all, just read the section called General guidelines.

Document outline

The document outline is the structure of sections in the document, built from the h1-h6 elements as well as the new sectioning elements (section, article, aside, nav). The document outline is more commonly known as the Table of Contents.

To make sure that you have used the new sectioning elements correctly, you can check that the resulting outline makes sense with the HTML5 Outliner.

If you see "Untitled Section" and didn't expect them, chances are that you should have used div instead of section.

If you have a subtitle of a heading that shouldn't be part of the document outline, you should use the hgroup element:

<hgroup>
 <h1>The World Wide Web Consortium</h1>
 <h2>Leading the Web to Its Full Potential...</h2>
</hgroup>

In this example, only the h1 will show up in the document outline.

Table inspector

(This only applies to table elements used for tabular data — not for layout.)

HTML tables have two types of cells: header cells (th elements) and data cells (td elements). These cells are associated together in the table: a data cell in the middle of the table can have associated header cells, typically in the first row and/or the first column of the table. To a user who can see, this association seems obvious, but users who cannot see need some help from the computer to understand which cells are associated with which.

You should mark up your header cells with the th element and check that your cells get associated as you intended using the Table Inspector. If it isn't as you intended, you can consider simplifying or rearranging your table, or you can override the default association using scope or headers attributes.

Other tools?

If you know about other tools for helping with quality assurance of HTML5, or if you have made your own, please share!

Posted in Conformance Checking | 4 Comments »

This Week in HTML 5 – Episode 32

Wednesday, May 6th, 2009

Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.

In this article:

Introducing the <hgroup> element

Topping our list of changes this week is the new <hgroup> element:

The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

Meanwhile, the <header> element has been redefined:

The header element represents a group of introductory or navigational aids. A header element typically contains the section's heading (an h1–h6 element or an hgroup element), but can also contain other content, such as a table of contents, a search form, or any relevant logos.

Here is an example of how these elements can work together in marking up a specification:

<header>
 <hgroup>
  <h1>Scalable Vector Graphics (SVG) 1.2</h1>
  <h2>W3C Working Draft 27 October 2004</h2>
 </hgroup>
 <dl>
  <dt>This version:</dt>
  <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd>
  ...
 </dl>
</header>

Relevant background reading:

(Re)introducing the accesskey attribute

Next up in this week's changes is the reintroduction and reformulation of the accesskey attribute. In HTML 4, the accesskey attribute allows the web designer to define keyboard shortcuts for frequently-used links or form fields. In HTML 5,

All elements may have the accesskey content attribute set. The accesskey attribute's value is used by the user agent as a guide for creating a keyboard shortcut that activates or focuses the element.

If the accesskey attribute is used on a non-link, non-form-field element, it defines a command, which has a specific meaning in HTML 5.

Also new in HTML 5: the accesskey attribute may contain a number of shortcuts, space-separated, and the new .accessKeyLabel DOM property contains the shortcut key that the browser ultimately chose.

One possible enhancement, not in HTML 5 but under consideration for HTML 6, is the use of more-than-1-character strings to define roles, such as accesskey="help". The browser could then choose the appropriate shortcut key based on the user's platform and preferences.

I plan to write up a more detailed history of the accesskey attribute in a seperate article. Until then, here is some background reading:

(Re)introducing the window.setTimeout and window.setInterval functions

The window.setTimeout and window.setInterval functions have been in a state of limbo in the HTML 5 spec, waiting for an editor to take them and split them out into a separate spec. No editor has come forward, so back into HTML 5 they go.

These timer functions are complicated by their unique history in browser-land. They can take basically anything as their first argument. If you pass a function, it will be executed after the specified interval. If you pass anything else, the browser will call toString() on the parameter and then evaluate it as a JavaScript expression in the context of the current window (or, if the timer function is called from a web worker, the current WorkerUtils object). There is also a little-known but widely supported third argument to setTimeout and setInterval, which passes arguments to the evaluated expression. Meanwhile, the second argument -- the timeout value -- can also be any datatype. Browsers must call toNumber(toString(timeout)) and round down to the nearest integer.

More <video> changes

It seems that each week in HTML 5 brings more changes to the <video> element. While this is not strictly true, it is certainly true this week.

Events

Speaking of events, there was a series of event-related checkins this week. The onundo and onredo events, usually triggered by the user selecting the Undo or Redo item from the Edit menu, have been moved from the Document to the Window. [3003] These events are important for all sorts of web applications (think Google Docs and then work your imagination outward).

r3004 adds support for the onbeforeprint and onafterprint events, which are supported in Microsoft Internet Explorer since version 5.

r3005 updates the global list of event handlers to include these new events, some video-related events, some storage-related events, and several others that have slipped through the cracks during the thrashing of these features.

Other interesting changes this week

Around the web

Tune in next week for another exciting episode of "This Week in HTML 5."

Posted in Weekly Review | 2 Comments »

This Week Day in HTML 5 – Episode 24

Tuesday, March 10th, 2009

Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group. The pace of HTML 5 changes has reached a fever pitch, so I'm going to split out these episodes into daily (!) rather than weekly summaries until things calm down.

The big news for February 13, 2009 is r2814/r2815, which adds a .value property on file upload controls:

On getting, [the .value property] must return the string "C:\fakepath\" followed by the filename of the first file in the list of selected files, if any, or the empty string if the list is empty. On setting, it must throw an INVALID_ACCESS_ERR exception.

According to bug 6529, Opera already implements something close to this, and is willing to modify their implementation to match the spec text.

The other big news of the day is r2804/r2805, which defines what happens when a focused element becomes hidden.

For example, this might happen because the element is removed from its Document, or has a hidden attribute added. It would also happen to an input element when the element gets disabled.

But let's back up a step. What does it mean for an element to be "focused" in the first place? The spec has a whole section on the concept of focus. The short answer is that focus is just what you think it is: it's the element that responds when you type. As you tab around a form, the focus moves between form fields, where you can type information; as you tab around a page, the focus moves between links, which you can follow; if you tab long enough, focus moves out of the page and back to the location bar, and so forth.

The not-so-short answer that everything in the previous paragraph is platform-specific and, depending on your browser, highly customizable. The HTML 5 spec respects these platform differences, and defers the definition of what elements should be focusable to the browser, which ultimately respects the conventions of the underlying operating system.

The long answer is that virtually anything can be focusable, because HTML 5 standardizes a crucial accessibility feature that most modern browsers now implement, namely that any element can have a tabindex attribute.

It may not sound like it, but this is a really, really important feature for building accessible web applications. HTML 4 restricted the tabindex attribute to links and form fields. For reasons unknown, Internet Explorer ignored that and respected a tabindex attribute on any element. Starting with Firefox 2, Mozilla co-opted this implementation and wrote up a rough "standard" about using the tabindex attribute on anything. Once it was implemented in the browser, IBM contracted with major screenreader vendors to support Firefox's (and IE's) behavior. This provided the foundation for pure-Javascript widgets to become keyboard-accessible (also implemented by IBM). Not just theoretically, but actually, in real shipping browsers and real shipping screenreaders. Under the covers, Dojo's complex widgets are marked up with semantically meaningless <div>s and <span>s, yet they are still focusable and keyboard-navigable. The controls are in the tab order, so you can focus with the keyboard, then you can use the keyboard to further manipulate them, change their state, and so forth.

In HTML 4, there was no way to put custom controls into the tab order without breaking markup validity (unless you futzed around with custom DTDs or scripting hacks), because the tabindex attribute could only be used on links and form fields. HTML 5 "paves the cowpaths" and standardizes this definition and behavior of tabindex-on-anything. This is a huge step forward for web accessibility. The concept of focus is central to accessibility, and HTML 5 gives it the attention it deserves. (There's more to making controls accessible than just keyboard navigability, but if you don't have keyboard navigability, nothing else really matters. If you're creating your own custom Javscript widgets, you must read the (non-vendor-specific) DHTML Style Guide for implementing keyboard accessibility in custom controls.)

Now then, why is r2804 important? Well, if the element that has focus suddenly can't have focus anymore -- because it was programmatically hidden or disabled, or it was removed from the DOM altogether -- then it is vitally important to specify where the focus goes. So the HTML 5 specification lays it all out:

When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead, the user agent should run the focusing steps for the body element, if there is one; if there is not, then the user agent should run the unfocusing steps for the affected element only.

[Background reading: Re: Lose Focus When Hidden? (SVG ISSUE-2031)]

Other interesting changes of the day:

Tune in... well, sometime soon-ish for another exciting episode of "This Week Day In HTML 5."

Posted in Weekly Review | 1 Comment »