Description

We had about 40 people in the room, who attended the event. About 26 of them were web accessibility professionals, who work in the field with developers. Of those about 4 had been in the field since at least 1999. Those who were in the field voted. We have their voting results below. The subjects were:

• Ambiguous link text
• Table summaries
• Complex tables requiring headers and ids
• Long descriptions for alternate text of images

Why have these seemingly simple issues not been resolved? Browser manufacturers, assistive technology vendors, standards producers, and accessibility professionals seem to struggle to provide consistent, predictable and reliable solutions for users.

Let's have a showdown

In this talk we had a showdown, to see what techniques would emerge as the winners in terms of elegance, browser support, accessibility support, ease of programming, and overall usability.

---

Ambiguous link text

Remember, “click here”, “read more”, “details” etc. WCAG Success Criteria 2.4.4 allows an author to rely on the containing sentence, or paragraph, but it never worked for screen reader users when pulled up in a links list. We see what options actually do work in JAWS, NVDA, and VoiceOver. The competitors are:

1. off screen supplementary text inside the anchor (2 votes)
2. aria-label (0 votes)
3. aria labelledby (15 votes) - Winner
4. aria-describedby (3 votes)
5. Wrap an anchor around everything (HTML5) (2 votes)
6. just straight unambiguous text (3 votes)

Ambiguous Link Text Examples and Test Results.

---

Table summaries

HTML introduced the table Summary as a way to provide an offscreen description that was programmatically associated with the table, for people who are blind. It never really made it outside of the accessibility ghetto and was deprecated in HTML5. Yet the need to understand tables has not gone away. Some people who are born blind have a very hard time conceptualizing tables, and they rely on a text description. Many developers and designers don’t want to provide a description before the table because of the screen real estate it requires. Here are the competitors:

1. In prose surrounding table with aria-describedby (18 Votes - Winner)
2. Inside the caption element (3 Votes)
3. After the figcaption in the figure Element (0 Votes)
4. Inside the Figcaption element (0 Votes)
5. “willful violation” of valid HTML5: Using the Table Summary attribute which is dropped from HTML5 (4 Votes)

Table Summary Examples and test results

---

Long Descriptions

The debate over the longdesc attribute has raged for years. It was introduced as an alternative to the “D” link strategy, which was the letter D in an anchor tag beside the image with a link to a long description on a separate page. (Probably only the oldest of us in this industry remember this). The longdesc attribute was never well implemented in the mainstream, and browser support and AT support  was inconsistent. It was deprecated in HTML5 but a void existed for a viable replacement and WCAG still required a long description be provided for complex images. Subsequently, the longdesc attribute was resurrected as a W3C extension, and as of this writing it is waiting on a decision about whether it will proceed with a formal objection against it from a major vendor. We will not enter into the longdesc debate, but rather look at options that are available to meet the WCAG requirements for long descriptions.  Contenders are:

• Simple link on page to a long description (5 Votes)
• In page descriptions referred to in the image alt, (1 Vote)
• The html5 figure element wrapped around the image and it’s long description (0 Votes)
• Expandable collapsible link used to hide the description on the page. (20 Votes -Winner)
• Longdesc (0 Votes)

Long Description Examples

---

Complex tables (not in talk but covered below)

Complex tables (with merged cells in the header rows) traditionally required headers and ids to ensure a programmatic relationship between data cells and their corresponding cells that would be read by screen readers. It is a difficult programming process for authors which was easy to mess up and difficult to test. Screen reader advancements render headers and ids unnecessary in modern AT for many tables with merged cells in header rows, but this is not true for all situations and all screen readers.

We will discuss the conditions where headers and ids are still necessary, the environments that don’t work with (or without) headers and ids, and we’ll discuss whether adding the scope attribute helps.

Complex Table Examples

(No voting in session ran out of time)

---

Bottom Line

We feel CSUN talks should be filled with useful information that participants will leave with. David thinks this round robin runoff approach to looking at these four issues can provide a basis to rally around solutions, and move towards consensus, so that they will no longer be issues at the next CSUN.

David MacDonald, advisor to the Government of Canada , 12 year WCAG member, CSUN regular, HTML5 accessibility task force member, and co-editor of the W3C document “Using wai-aria in HTML5” will provide a brief history of why there was so much debate, why prior solutions failed, the new html5 and wai-aria solutions. There will be a discussion of the current options, best practices, and current accessibility support for these long term accessibility conundrums.

Feel free to comment on Twitter @davidmacd

Author information:

David MacDonald is a veteran WCAG member, co-editor of Using WAI ARIA in HTML5 and HTML5 Accessibility Task Force Member. Opinions are my own.