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.


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, Techniques for describing tables. (Also in HTML5 technique 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>

CSUN14 Review

Another CSUN conference has come and gone, and they only get better each year. Of course I’m referring to the CSUN (California State University, Northridge) Annual International Technology and Persons with Disabilities Conference which happens at the incredible Manchester Grand Hyatt Hotel in downtown San Diego, California.

The conference was officially kicked off Tuesday evening with a keynote speech by Tommy Edison (starts at 9:45) who is also well known as the @BlindFilmCritic.

Tommy Edison
Tommy Edison, standing at the podium, presents the keynote address at CSUN14.

Events & Happenings

Besides the plethora of sessions to attend, many events (official and unofficial) and fun things were going on:

Highlighted Sessions

There are too many great sessions to note, but here’s are several to get you started:

Summary Next Year’s 30th

Next year is the 30th CSUN and promises to be even bigger and better than ever. Seriously, there are tremendous plans for CSUN15 are already under way. Hope to see you there!

More Resources

Detecting Screen Readers – No

There has been much discussion about the idea of detecting a screen reader from a website and optimizing the code. In the W3C editor’s draft IndieUI 1.0: User Context, screen reader detection is proposed. This scares me and many others in the web accessibility community.

In the recent publishing of the WebAIM screen reader survey, one of the questions is “How comfortable would you be with allowing web sites to detect whether you are using a screen reader?”. Surprisingly 54% of respondents replied “Very comfortable”. This sure sparked some discussion on Twitter and on blogs.

For the most part, detecting a screen reader has been ill-received from the accessibility community. I am also strongly opposed to this idea.

The reasoning boils down to two issues: development and privacy. And it’s bad for both. Here are some reasons why it’d be bad for development:

  • Text-only websites didn’t work before and you know devs will do this if a mechanism is provided.
  • Screen reader detection is eerily similar to the browser-sniffing technique which has proven to be a poor practice.
  • Maintaining separate channels of code is a nightmare; developers overloaded already with supporting multiple browsers, devices, etc (via RWD). And if done, it will many times become outdated if not entirely forgotten about.
  • Why screen reader detection? If you follow that logic, then detection should be provided for screen magnifiers, braille output devices, onscreen keyboards, voice-recognition, etc. That’s just crazy.

Let’s hope screen reader detection is removed from the W3C draft of IndieUI 1.0: User Context.

PS: Interestingly, @LFLegal recently announced that Safeway is (finally) removing a text-only version of its website in the blog Separate is Not Equal: Good News for Grocery Delivery.

Further reading:

Podcast #99: Jennison Powers Up Silicon Valley

Dennis speaks with @Jennison Asuncion about his big move to Silicon Valley from Toronto, new Meetup groups and camps, CSUN14 and other fun things.

Download Web Axe Episode 99 (Jennison Powers Up Silicon Valley)

[transcript of podcast 99]

Event announcements:

More new groups:


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: