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.
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.
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>
Two hack-a-tons occurred which was great! A TPG Bug Bash and an ARIA Hackathon by organized by @JohnFoliot.
I attended the Project Possibility’s SS12 Finals where the “Code for a Cause” contest is concluded. The contest is among university teams for the best accessible application. The winner was the CSUN team for a camera app for the blind.
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.
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.