Category: html5

Clearing Up Summary

The summary attribute is a “classic” method to describe data tables to screen readers users. It’s mentioned in Section 508 and even in WCAG 2.0 technique H73. But this technique is outdated and I haven’t recommended its use for a while now.

Reasons not to use the summary attribute

Why don’t I recommended its use? Here are some reasons:

  • Many web editors don’t support it.
  • Because it’s not visual, the content can be easily be forgotten and therefore outdated/irrelevant.
  • Screen readers can automatically tell the user how many rows and columns a data table has so summary isn’t needed for this.
  • It’s deprecated in HTML5.
  • There is an ARIA alternative.

Misinformation

In the past, two web professionals, supposedly knowledgeable in accessibility, thought that the HTML5 Summary element (together with the Details element) can be used in place of the summary attribute. This is wrong. The Details/Summary elements are not related to the summary attribute and data tables.

And if you’re wondering, the Details/Summary elements are HTML5′s solution to toggle functionality. Browser support for Details/Summary is not quite there yet.

The ARIA Alternative

A description of a data table isn’t needed (and therefore a summary attribute) if the table is simple and clear (one header level, succinct header text, caption provided, etc.). If a description is needed, the text should be placed in the main content itself. This text can then also be associated to the table with ARIA.

In the HTML 5.1 Nightly, you’ll see the ARIA technique, 4.9.1.1 Techniques for describing tables. (Also in HTML5 technique 4.9.1.1) This is the proper way to use ARIA in place of the summary attribute to describe a data table.

Addendum: Thanks to @DBoudreau for pointing out the the tabindex=0 is required at this time for this to work properly for all screen readers.

<p id="tblDesc">The following table displays student population data of Foobar High School between 2003 and 2011 as computed by the XYZ Corporation.</p>
<table aria-describedby="tblDesc" tabindex="0">
 <caption>Student Population of Foobar</caption>
 <thead>
  <tr>
   <th>Year</th>
   <th>Population</th>
   <th>Change</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>2003</td>
   <td>846</td>
   <td>-3</td>
  <tr>
   <td>2004</td>
   <td>855</td>
   <td>+9</td>
  </tr>
 </tbody>
</table>

Vimeo Updates Video Player Including Accessibility

Vimeo, a YouTube competitor, has recently updated its web-based video player. Vimeo now defaults to an HTML5-based player rather than Flash. It provides much faster playback/load times and improved tools to share a video.

Vimeo logo

Although the accessibility implementation may not be perfect, it’s a very significant improvement. The Vimeo player now supports keyboard and screen reader users and supports captions and subtitles! Here’s a live example of Vimeo captions by Amara (@AmaraSubs).

Thanks to Vimeo for these changes. We hope to hear about more improvements.

Further reading:

Longdesc Links, History, Future

Recently I Twittered daily about longdesc, the classic unsung HTML attribute which supports long descriptions of images. Here’s a summary of the tweets/links:

Some History

To make a long story short (pun intended), longdesc was made obsolete in HTML5 but then returned. I applaud @JohnFoliot, @Laura_Carlson, and @Chaals in their dedicated efforts to return longdesc. I agree it should remain as there is no sufficient ARIA replacement.

Here are more great links on the topic on long description over the last few years.

The Future

Check out the ARIA 1.1 spec for aria-describedat! The aria-describedby attribute is like a combination of longdesc and aria-describedby. I’m pretty excited about this as it seems to provide a method for long description that we can all agree on.

Accessible HTML5 Media Players and More

Here’s a list a accessible HTML5 Media Players—I have not tested them all—and some articles on how to build one yourself. Know any others? Please leave info in a comment.

Existing Players

Do It Yourself

More

Response to MSDN Article “Designing Accessibility with HTML5″

This blog is a review/response to the recent MSDN article Designing Accessibility with HTML5 by Rajesh Lal (@irajlal). The article is quite extensive and covers an intro to accessibility and disability, progressive enhancement, ARIA, forms, tables, and more.

I had actually reviewed an early version of this article, but it seems some of my feedback was not incorporated, and there is also some new content in the article. So let’s discuss some of those items and more.

The introduction does an adequate job of covering the four main types of disabilities: hearing, mobility, cognitive, and visual. For reference, here’s the link to the WCAG 2.0 POUR model (perceivable, operable, understandable, robust) as mentioned.

Progressive Enhancement

I was happy that Progressive Enhancement (PE) was mentioned next, early in the article. I firmly believe that semantic markup and PE are essential to a robust and accessible webpage. PE was described fairly well, but then I was disappointed to see example code further down the page which does not use PE. In Figure 9, the form example is missing a URL in the action attribute and contains the following line to submit:

<div><a href="#" onclick="submit()">Send Your Message!</a></div>

This line does not represent proper semantic markup, progressive enhancement, nor the non-JavaScript use case. A better example would be to add a dummy URL in the action attribute, and for the submit button, do this:

<input type="submit" value="Send Your Message!" />

Headings

In Figures 6 and 7, home page sample code, the document outline is broken. The heading order jumps from H2 to H4 so is missing the H3. It also appears that the H4 elements in the aside element are correlated to the last H2, which in incorrect; they are separate topics. To solve, I would insert an H2 heading in the aside element and change the H4 elements to H3. In addition, there is no H1 element.

Figure 11, Markup for a FAQ Page, does indeed provide an ideal heading structure.

A perfect heading structure is not essential, but certainly helps. Especially when the code is an example for other developers.

And for the record, in Figures 6 and 7, the image element for the logo is missing alt text.

JavaScript Insertion

It’s good that the author recommends placing the external JavaScript files at the end of the body (at end of home page section), but remember that you may need to put certain JavaScript at the top, mostly scripts for feature detection such as Modernizr. (This isn’t really accessibility but thought I’d include anyway.)

Fieldset/Legend

In the Contact Form section, I really like that the sample code is using the placeholder attribute correctly. But there’s one issue; the fieldset element is being used but the legend is missing. The spec oddly says legend is optional, but it’s definitely best practice to use it. Otherwise, there’s no reason to use fieldset in the first place as far as I know.

Data Table

In the data table, use of a caption element is great, but I’m perplexed as to why there is a details and summary element within the caption. And I wouldn’t recommend using a strong element with the caption text; use CSS instead. Also, the TH elements should have a scope attribute; it may not be necessary with newer assistive technologies, but makes the code more robust and semantic.

Links, titles, and abbreviations

Towards the end of the article, there’s a section on links and images. I really advocate this advice: Use a CSS background image if your design requires an icon such as “>”.

Just before that, I have issues with the sample text link. Avoid “click here” is good, but then the title attribute contains “click for”. This somewhat of a moot point as the title isn’t needed at all. Traditionally, the title attribute is only needed for additional supplementary information (not required for user). The mighty Steve Faulker, in his article Using HTML title attribute, suggests that title only be used in a couple rare cases.

For images, I would not recommend the title attribute here either (due to lack of support). For even more on that, check out this recent article about title attributes on the RNIB site.

About the link underline, of course I agree that text links (in main content especially) should be underlined. The sample CSS adds the underline, but it’s much better to do this by not removing it in the first place. The underline does not have to be added; it should already be there by default.

The abbreviation example is simple and solid, but there’s more to it than that. Because of poor support, the title attribute doesn’t work typically with the keyboard and some assistive technologies (see links above). Therefore, I strongly suggest that the full text of the acronym or abbreviation is written out when it first appears on each page.

Final Thoughts

I don’t have much to say about the audio/video section; I’m just wondering where the keyboard shortcuts listed for the HTML5 media controls comes from.

It’s great to see that Visual Studio 2012 has ARIA support. I know it’s still a popular application, but I don’t have much experience with it myself.

The MSDN article Designing Accessibility with HTML5 has a lot of good information and tips. But many times, especially with accessibility, the devil is in the details. It is quite a tricky topic and there are many nuances and gray areas. I hope this response has cleared up some of those.