Summary

The purpose of the summary attribute is to concisely describe the structure of a data table. The summary attribute is not intended to provide a long description for data tables.

Author: Gez Lemon

The summary Attribute

The purpose of the summary attribute is to provide a concise overview of the structure of data tables. WCAG 2.0 covers this issue under guideline 1.3.1: Information and relationships, where they have a success criterion for using the summary attribute to provide an overview of data tables. The summary attribute is most useful with complex data tables, but can also be useful with simple data tables. Without a summary attribute, assistive technology users need to investigate the data table one cell at a time to build up a mental picture of the structure in their mind. With complex data tables, where columns and/or rows are grouped, building a mental picture can be particularly difficult for non-sighted users, whereas this information is visually obvious to sighted users. Sighted users of any ability are able to determine the structure of the table visually, whereas non-sighted users have no such luxury without the author providing a summary attribute to describe the structure of the data table.

Long Descriptions for Data Tables

The HTML 4.01's definition of the summary attribute uses the term purpose in its definition, which, along with the summary attribute's name, seems to have confused the purpose of the summary attribute.

This attribute [the summary attribute] provides a summary of the table's purpose and structure for user agents rendering to non-visual media such as speech and Braille.

The summary attribute is not intended to provide a long description for data tables.

• Long descriptions are better provided with markup, as markup provides a convenient mechanism for assistive technology users to interact with the content. Assistive technologies that support the summary attribute read it by default. Forcing a long description on assistive technology users is obviously not desirable.
• A long description benefits all user groups, and shouldn't be hidden within the table.
• WAI-ARIA already has a mechanism to describe long descriptions that can be used with any object. For consistency, aria-describedby should be used to associate a long description with any object.
• The summary attribute serves a particular audience in providing an overview of the structure of the table that cannot be determined by the markup for the table alone, and is redundant for sighted users.

All sides of the debate agree that if a long description is required, the long description should be provided to all groups, not just screen reader users. The best mechanism to provide a long description is to provide a generic description of the table that is available to all users, and make the association using WAI-ARIA's aria-describedby attribute.

Misconceptions about the summary Attribute

Describing the summary attribute as a long description is dangerous, and almost guaranteed to result in the summary attribute being omitted from HTML5 and later versions. If the summary attribute is omitted from HTML5, user agent support for the attribute is likely to disappear from user agents, even though the attribute is currently very well supported. The summary attribute serves a particular audience; those that cannot determine the structure of the table visually.

The purpose of the summary attribute is to define the structure of data tables to non-sighted users where the relationship cannot be determined by user agents. User agents typically provide the number of columns and rows, but only an author can provide semantic information, such as the rows contain the time the bus leaves a particular bus depot, and the columns contain the destinations for each journey. That information is readily visually available, but a screen reader user would need to examine several cells before they can build that association in their minds. Structural information about how a data table is to be read visually can readily be provided by an author using the summary attribute.

Summary

I'm putting together a list of pros and cons about making the alt attribute required in HTML 5. The following is a list of reasons for and against making the alt attribute required. What is your opinion?

Requesting Opinions about the alt Attribute

I asked on Twitter whether people thought the alt attribute should be a required attribute on the img element, along with the reason why. The purpose is to come up with a balanced list of pros and cons. The response has been quite good, although some people didn't provide a reason. The following is a summary of the reasons provided so far.

Reasons why the alt Attribute Should Be Required

• If the image is decorative, it should be provided with CSS. If the image has content, then the alt attribute should be used or the content will not be perceivable to some users.
• The alt attribute should be mandatory in HTML 5 with a note pointing to WCAG 2.0 for guidance, as WAI are the experts in this area.
• Not requiring the alt attribute allows broad, dangerous ideas of what should and should not have alt. Laziness will dictate.
• Authors should be required to make a decision about alt text for every image.
• Without alt text, assistive technologies rely on heuristics to determine the purpose of the image, which often results in gibberish — for example, announcing machine generated file names as the link phrase for links.
• Bad alt text is much better than no alt text.
• Requiring alt text encourages people in the right direction.
• Because people don't always get the alt text correct, it is not a reason not to require it.
• Requiring alt text creates a teachable moment.
• The alt attribute should be required with an additional attribute to indicate when it hasn't been provided.
• The alt attribute should be required for backward compatibility.
• There has not been a convincing argument for what lack of alt should mean.

Reasons why the alt Attribute Should Not Be Required

• Making the alt attribute required results in people providing nonsense values.
• It's not reasonable to expect anyone to provide alt text when uploading several thousand photos all at once.
• Making the alt attribute required does not mean it will be used correctly.
• Provide the alt text with aria-labelledby is better than requiring the alt attribute.
• Providing alt text should be considered best practice, not required.
• Requiring alt text is merely philosophical without context.
• The alt attribute should not be required, but flagged at validation as a warning.
• There are exceptions where no value is possible.
• There are illustrative images that do not require alt text.
• Images on my website are for my family, and they don't need alt text.
• The alt attribute should not required because authors get it wrong, in the same way they get other markup wrong, such as data tables without headings.
• All that is required for accessibility is that the alt attribute may be used; it should not be required.

What do you Think?

Do you have reasons other than those already stated about whether or not the alt attribute should be required in HTML 5? If so, either leave a comment here, or contribute to the Twitter discussion or respond to me directly on Twitter. If you respond on Twitter, please use the #althtml5 hashtag so that I can find your response.

Summary

Steve Lee tagged me with the "Seven Things" meme, where you have to share seven facts about yourself and tag seven people to pick up the meme.

Rules of the Seven Things Meme

1. Link to your original tagger(s) and list these rules in your post.
2. Share seven facts about yourself in the post.
3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
4. Let them know they've been tagged.

My Seven Facts

1. I am an excellent guitarist. When I lived with my parents, our next door neighbour threw a brick through my bedroom window so he could hear better. He started to sing along, but was completely out of time and got all the words wrong.
2. I can also play the piano, but not as well as I can play the guitar. I have the capacity to learn one song all the way through, but if I learn another, the previous song I learnt gets overwritten.
3. My Dad is a drummer. I miss having a drum kit around. If I get a detached house, I will get a drum kit.
4. I gave up smoking nearly three years ago.
5. I can levitate, but not all at once.
6. I can't play golf.
7. I don't know seven people to tag with this meme.

I can only think of one person to tag with the seven things meme:

1. Henny Swan

Summary

Considering the standard Twitter website is so basic, it's surprising it is so inaccessible. This Focus Twitter Greasemonkey script puts the favourite, reply and delete links into the keyboard tab order to make it easier for keyboard-only users to use Twitter.

Contents

• Twitter Accessibility
• Similar Functionality; not an Equivalent
• Finding a Solution
• Installing the Greasemonkey Script

Twitter Accessibility

There are many accessibility problems with Twitter, but by far the biggest issue is having links that can only be activated using a mouse. The links for making a particular tweet a favourite, the links for replying to a particular tweet, and the links to delete a tweet or direct message can only be activated using the mouse on the standard Twitter website. The favourite, reply and delete links are revealed when the user hovers the mouse over a tweet.

Hiding actions and only revealing them when the user moves the mouse results in a very poor user experience, as many mouse users will be unaware that the functionality exists at all. For keyboard-only users, the situation is far worse, as they could never possibly know the functionality exists.

Similar Functionality; not an Equivalent

Twitter has a set of commands to use with Twitter updates, including a @username command to send a reply to a particular user. The syntax is @username message you want to send to the user. Whilst useful, there are two significant difficulties with this syntax:

• The reply is associated with the last tweet the user sent. If the user has sent tweets since the particular message a user intends to reply to, the reply is associated with the wrong tweet. By contrast, the reply is always associated with the correct tweet when using the reply button.
• The user has to physically type the username. As usernames aren't always simple to remember, the user sometimes has to copy and paste them. By contrast, the name is automatically put into the reply box with the correct syntax, and associated with the correct tweet when a user hits the reply button.

Using commands to manually send replies is not an equivalent for a button that does everything for the user.

There is also a FAV command to make a tweet a favourite. The syntax is FAV username, which will make the last tweet by the user a favourite. Like replies, the FAV command assumes the very last tweet from a user, and requires the user to type the username.

Keyboard-only users cannot delete tweets, as there are no commands for deleting tweets or direct messages.

Finding a Solution

There are so many accessibility issues with Twitter that I originally wanted to build an accessible Twitter application. The problem is that I wouldn't have the bandwidth to run a server-side Twitter application, and Twitter doesn't currently use OAauth, which means I would have to ask users to trust me with their usernames and passwords. When discussing this on Twitter, Derek Featherstone (feather) suggested writing a Greasemonkey script. This was a good idea, as it at least allowed the biggest accessibility problems to be addressed immediately.

The Greasemonkey script reveals Favorite, Reply and Delete links when appropriate for each tweet in the timeline. The link phrases have contextual information for assistive technology, but hidden visually, as the links are clearly grouped with the tweet to which they belong. I also removed the avatar from the keyboard tab order to reduce the number of redundant links for keyboard-only users, as the name immediately by the side of the avatar activates the same link. I have left the link in place so that mouse users have a larger target area, as they can click on the avatar.

Installing the Greasemonkey Script

If you don't already have Greasemonkey installed, you will need to install Greasemonkey in Firefox first. After installing the extension, select the Focus Twitter Greasemonkey script, and you will be prompted to install the script. From then on, you will have access to reply, favourite and delete links using the keyboard.

Summary

The Accessibility Evaluation and Repair Tools (AERT) colour contrast algorithm was never a recommendation. As the luminosity contrast ratio algorithm is recommended with WCAG 2.0, it is now the main method of testing colour contrast on Juicy Studio.

AERT Suggested Algorithm

The 26th of April 2000 working draft for AERT contains a suggested algorithm to calculate the contrast of foreground and background colours, based on the YIQ colour space previously used by the NTSC television standard:

Color brightness is determined by the following formula:

((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000

Note: This algorithm is taken from a formula for converting RGB values to YIQ values. This brightness value gives a perceived brightness for a color.

Color difference is determined by the following formula:

(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))

A colour brightness difference of over 125 and a colour difference of over 500 is a pass using this algorithm.

Absence of an Official Algorithm

In the absence of any other published algorithm to determine colour contrast, I decided to use the proposed AERT algorithm to test for colour contrast. The algorithm was better than nothing, but there were problems with the algorithm failing colour combinations that were obviously good, and allowing colour combinations that were obviously poor.

The biggest problem with the AERT algorithm is that the colour difference was too strict and barred obviously good colour combinations. To get around this restriction, Hewlett Packard lowered the threshold to 400. The algorithm also allowed colour combinations that were obviously not good, such as #f80 and #00f (bright blue on orange). The colour combination is difficult to read, yet passes the AERT algorithm. The difference in brightness is 127 (threshold is 125), and the difference in colour is 646 (threshold is 500).

Luminosity Contrast Ratio

The Luminosity Contrast Ratio algorithm, developed by Gregg Vanderheiden, Dave Kelso, and Aries Arditi at the Trace R&D Center has been adopted by WCAG 2.0. Success Criterion 1.4.3 requires the visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

The luminosity algorithm provides much better results than the old AERT algorithm. The obviously poor colour combination of bright blue on an orange background (#f80 and #00f) yields a luminosity contrast ratio of 3.59:1 — a failure of success criterion 1.4.3, except for large text.

Colour Contrast Services

The old URL for the AERT colour contrast service on this website now redirects to the luminosity contrast ratio analyser (HTTP 301: moved permanently). The old AERT colour contrast analyser is still available, but through the new URL. The Juicy Studio Accessibility Toolbar and the Colour Contrast Analyser Firefox extensions will continue to include the AERT algorithm alongside the luminosity contrast ratio algorithm in the meantime.

Today is the 36th annual World Hello Day.

The idea is to encourage world leaders to use communication rather than force to settle conflicts. Participate by simply greeting 10 people today.

Hello, world.

I have updated the accessibility extension to display all WAI-ARIA properties.

ARIA Properties

I've added a function to the toolbar to display all ARIA roles and properties defined in a document. The properties are displayed in a new tab, along with the value of the property, the element the role is defined on, the parent nodes, and the markup fragment. The following is example output from running the function.

The properties functionality is a catch-all to report all ARIA properties. The toolbar can highlight live regions, document landmark roles, and general roles individually.

I have updated the accessibility extension to display all WAI-ARIA roles.

ARIA Roles

ARIA introduces the role attribute to help define widgets, such as a tree, and define page structure, such as the navigation section. The accessibility toolbar displays the roles defined in a document in a new tab, along with the element the role is defined on, the parent nodes, and the markup fragment. The following is example output from running the extension.

At the moment, there isn't a check to ensure that the role provide is a valid role. The next version of this toolbar will highlight invalid role names.

I have updated the accessibility extension to investigate WAI-ARIA document landmark roles.

Document Landmark Roles

WAI-ARIA defines document landmark roles to help define the structure of a document. Document landmark roles have two purposes; they help assistive technology users orientate themselves within a document, and they provide a mechanism for users to navigate documents. The following document landmark roles are defined in ARIA.

article

Content that makes sense in its own right, such as a complete blog post, a comment on a blog, a post in a forum, and so on.

banner

Site-orientated content, such as the title of the page and the logo.

complementary

Supporting content for the main content, but meaningful in its own right when separated from the main content. For example, the weather listed on a portal.

contentinfo

Child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.

main

Content that is directly related to or expands on the central content of the document.

navigation

Content that contains the links to navigate this document and/or related documents.

search

This section contains a search form to search the site.

The following markup example specifies the document landmark roles for the banner, navigation, and main to create the page structure for a typical web document.

<div role="banner">
...
</div>
<div role="navigation">
...
</div>
<div role="main">
...
</div>

Document Landmark Roles Extension

The accessibility extension includes a menu item to investigate the document landmark roles. The extension draws an outline around the elements containing document landmark roles, along with the name of the landmark role.

This website contains document landmark regions for main, search, navigation, and complementary, so is ideal for testing this extension. Document landmark roles are an easy ARIA win, so add them to your website and let me know the results of using this extension so I can ensure it works properly.

Known issues

When document landmark roles are contained in other document landmark roles, the name of the role might be written over the top of other document landmark roles. This will be fixed, but is a low priority at the moment, as the scenario is rare. The final version of this extension is likely to present all roles in a separate dialog.

TPG are working with the Mozilla foundation to develop accessibility testing tools. Specifically, we're developing WAI-ARIA tools, as well as improving accessibility of mainstream tools such as Firebug and providing ARIA testing features in mainstream developer tools.

As part of that work, this Firefox extension examines WAI-ARIA's Live Regions (this functionality will eventually be incorporated into a WAT for Firefox extension). The live regions extension is currently available in a toolbar with the latest versions of the colour contrast analyser and table inspector extensions.

I plan to add a set of accessibility auditing functions to this toolbar to make it easier for people to test websites for accessibility. At the moment, the toolbar consists of just three functions:

• Live Regions
• Colour Contrast Analyser
• Table Inspector

Live Regions

The live regions function adds elements with live regions defined into the tab order. When the elements are examined, a dialog is presented with 3 sections.

• The ARIA markup
• A table containing the relevant ARIA attributes
• An explanation of the ARIA markup

Visit iCITA live region examples to see live regions in action.

Colour Contrast Analyser

The colour contrast analyser examines the foreground and background colours of text nodes, and produces a report to determine if the contrast is adequate according to the AERT algorithm and the WCAG's luminosity colour contrast algorithm.

Table Inspector

The table inspector reveals the accessibility properties such as the summary and headers for table cells.

Download the Extension

Download the Juicy Studio Accessibility Toolbar from Firefox Add-ons. Unfortunately, the extension is sandboxed at the moment, which means you have to have an account in order to download the extension. Hopefully, the extension will be reviewed by someone that understands the purpose of the extension and remove it from the sandbox section (although the reviewer of the colour contrast analyser decided to leave it in the sandbox).