WebAIM Blog

The folks here at WebAIM are pleased to be attending The 25th Annual International Technology & Persons with Disabilities Conference, more commonly known as the CSUN conference. This conference is one of the highlights of our year. We love interacting with and being educated and invigorated by so many people that are passionate about accessibility.

We’ll be presenting the following sessions:

• Accessibility of Rich Internet Applications (pre-conference workshop)
• Insights Into Cognitive Web Accessibility
• The Myth of the Typical Screen Reader User
• Institutional Self-Study of Web Accessibility: Continuous Improvement for Our Nation’s Campuses
• A Beginner’s Introduction to WAVE
• Web Accessibility Preferences are for Sissies… and Other Universal Web Accessibility Concepts
• WAVE as Part of a Group-Wide Web Accessibility Plan

If you’re interested in attending, be sure to reserve your seat now.

WebAIM, in conjunction with several other fine organizations, is also sponsoring a CSUN Tweetup. We hope to see you there.

And for those attending SXSW Interactive, I’ll be presenting on Monday a session titled Web Accessibility Gone Wild.

Several years ago I read an article by Garrett Dimon titled “User preferences are for sissies” (available at archive.org, also see this 37signals article). The general idea is that when you present preferences to the end user it typically indicates that you screwed up or are a sissy – either you are forcing the user to account for a poor design or usability decision, or you are too indecisive to make the decision to begin with and thus place the burden to decide upon the user.

In general, I believe that web accessibility preferences are no different.

There may be places where accessibility preferences, widgets, or controls are justified. My point is that they always come at a very steep cost – and that developers should balance the possible advantages of web accessibility preferences with the significant disadvantages.

Consider font resizing widgets – the stack of letter A’s that allow one to increase or decrease the font size for a particular web page or site. First, if your font size is too small, why not simply make it adequately sized rather than forcing the user to make it bigger? But assuming that your page’s font sizing is already adequate, who would benefit from a font resizing widget? Users with poor vision, right? But users with more extreme low vision will already be using a screen enlarger or some other mechanism for zooming the page or increasing the font size, so your widget does them little good. Many users who prefer or need larger text will be using the zoom function that is available in all major browsers to provide the larger text on all web pages they encounter. The more accurate response to the question is users who have low vision or who might prefer larger text, but who are not already using technology or browser functionality to provide it. This is a rather small body of users.

Now, who gains no benefit from or could be potentially disadvantaged by a font resizing widget? The short answer is EVERYBODY ELSE!

As noted above, many users with low vision will already have larger text. Users who are blind generally don’t care how big the text is, yet they must listen to and navigate through the widget controls on every page. Users with motor disabilities who use only the keyboard must also ‘tab’ through these controls while gaining no benefit from them. Users with auditory disabilities gain no benefit. Users with cognitive disabilities must handle the additional cognitive load of these controls (what does a stack of increasingly sized A’s mean anyway?). And most notably, users with adequate vision gain no utility from the widget (again, assuming your default font size is adequate), yet are still presented with the control on each and every page.

So, while the font resizing widget has potential to provide some benefit for a small number of users, it serves no benefit and can only make the experience less accessible for everybody else.

The same can be said for nearly every other type of accessibility preference. A preference to enable a high contrast view is provided to either account for poor default contrast or to provide accessibility to a small group of users at the cost of burdening all other users with the contrast control. Text-only versions are typically provided to account for poor accessibility of a main page and may benefit some users (though our surveys indicate they are rarely accessed by these users anyway), but they increase the complexity of the page to everybody else. Even something as seemingly innocuous as an accessibility statement link or badges stating your compliance with standards come at a cost while providing negligible benefit to end users. The cost and benefit of each of these should be considered.

There may be exceptions to the “web accessibility preferences are for sissies” rule, but they are few. “Skip” links are one possible exception, but their days are numbered. They remain necessary only because most browsers have yet to provide meaningful methods of keyboard navigation within pages. Sites that target people with disabilities may find such preferences to be acceptable.

Universal design, like most aspects of web accessibility (consider alternative text for images), is about making solid decisions that are enforced upon users to ensure a highly effective user experience. These decisions must be informed and are often difficult to make. The idea that using accessibility preferences, widgets, or controls to account for poor accessibility or design decisions is a dangerous one that rarely results in overall improvements to accessibility.

We’ve reported over the last several years about the target.com lawsuit and eventual settlement. The $6,000,000 settlement required that Target would implement accessibility for users with visual disabilities, among other things. We’re happy to report that the target.com web site is now quite accessible. Sporting a new design and accessibility features, the site can be considered a wonderful model of an accessible corporate e-commerce site. The National Federation of the Blind considers the site equally accessible to blind and sighted users. While you may not agree with the lawsuit or may have concerns about the impact it has ultimately had on people with disabilities, it’s clear that this site is more accessible now than it likely would have been otherwise.

While we will likely never know the cost of implementing accessibility on this site (and indeed we shouldn’t treat the price of accessibility as something separate from site design and development anyway), I suspect it cost them much less to implement the current levels of accessibility than it did for them to fight and settle the original lawsuit. The new site maintains a clean and stylistic design with nearly all accessibility happening naturally through the structure and presentation of the site pages. Their implementation of “skip” links is fantastic – try tabbing through the page. There is certainly room for some improvement, particularly in other areas of accessibility not addressed by the NFB settlement, but the point is that the site is functional, looks good, and is quite accessible.

Target, along with Amazon.com and a few other innovators in the e-commerce arena, is showing that accessibility of large, complex sites is not only possible, but beneficial to all potential customers and to the corporations themselves.

Data Tables vs. Layout Tables

Screen readers treat data tables differently than layout tables. Layout tables are not identified and are read linearly as standard page content. Data tables, however, will be identified, the number or rows and columns read, and functionality provided for users to navigate through the table by cell.

While tables have never been intended to control layout, they often are used this way. The problem is that there is not a clear way to identify whether a table is being used for tabular data or for controlling layout. Screen readers, therefore, apply heuristics to determine the type of table encountered. The heuristics in the popular JAWS screen reader are very poor.

JAWS Behavior

UPDATE: In response to the details provided here, Freedom Scientific reports that JAWS 11.0.756 released Dec. 17, 2009 resolves many of these issues and now accounts for the presence of table headers in it’s consideration of table type.

Data tables should typically be assigned table headers (the <th> element) for all header cells. The presence of a <th> element in a table should be a dead giveaway that a table is intended for data. I’ve seen very few instances of the <th> element inappropriately used in layout tables. However, JAWS does not consider table headers or any other markup commonly used in data tables to determine the table type.

Instead, JAWS assumes the presence of a data table if it has at least 2 rows and 2 columns AND at least 4 cells in the table are between 200 and 16000 square pixels in size. 16000 square pixels is not much – a long sentence of default text or a small 200X80 pixel image.

Additionally, JAWS will treat tables with the DataTable=true or DataTable=1 attributes as data tables. Because this attribute is neither commonly used nor standards compliant, this will not be discussed as a viable solution to the problem, though it could be implemented as a ‘hack’ if need be.

This logic leaves much to be desired. It results in many data tables being incorrectly treated as layout tables, even if those data tables have appropriate header or other accessibility markup. Likewise, layout tables may be identified as data tables.

Examples

Consider the following simple table:

This is clearly a data table. Table headers and a caption have been provided. However, in JAWS this table is not read as a data table because there are only 3 cells (those in the left hand column) that are less than 16000 square pixels (at least at standard resolutions and settings). The sentence of text in the last cell makes that cell and all other cells in that column more than 16000 square pixels. JAWS users navigating this table will not get additional accessibility functionality.

Similarly, the following simple layout table which has no headers identified will be identified by JAWS as a data table simply because more than 4 cells are between 200 and 16000 square pixels in size.

	WebAIM Logo
	150X76 pixels
	6kb
	WAVE Logo
	76X76 pixels
	4kb

To compound this issue, JAWS analyzes the rendered size of the cell only, regardless of the cell contents making it virtually impossible for developers to control JAWS behavior. This means that users who increase their font size or zoom the page contents in their browser are more likely to have data tables be interpreted as layout tables because they are more likely to have cells over 16000 square pixels. This is particularly concerning because JAWS users with low vision are very likely to have enlarged content.

Now What?

ARIA does provide some assistance. Adding role="presentation" to the table causes it to always be treated as a layout table and adding ARIA role="grid" causes any table to be treated as a data table (note that with JAWS’ updated table detection heuristics, role="grid" is likely not necessary, and it could potentially cause confusion). This is supported in JAWS 10+.

Screen readers need heuristics to handle tables that are not coded with accessibility in mind, but no screen reader should ever treat a table with proper header markup as a layout table just because cells in that table happen to be big. Likewise, a layout table should not be treated as a data table just because none of the cells happen to be big. Hopefully Freedom Scientific will address this issue, though this is rather unlikely considering their responsiveness to such issues in the past (update – this issue has been at least partially resolved in JAWS 11.0.756). There’s little that developers can do about this issue. They should continue marking up data tables for accessibility as best as they can and transition away from using tables for layout. Additionally, screen reader users can use NVDA or another screen reader that handles tables appropriately.

It may be trite, but this is a season of thanksgiving and of reflection. While many of us experienced our yearly turkey-laden thanks this past week with family and friends, WebAIM is celebrating 10 years of thankfulness for our work, and for your participation in the web accessibility community.

Few know that this past year marked WebAIM’s 10th birthday. Frankly, we have been so busy we almost missed it ourselves. What began in 1999 as a small federal grant (Department of Education – FIPSE) to provide awareness of the need for web accessibility and a few resources has grown to become one of the most trusted names in web accessibility.

I chuckle when I use the Internet Archive to look at where we began (please – do it, it is hysterical), and I am amazed at the traffic our current web resources receive. I continue to be humbled that we are consistently listed in the top few Google results for “web accessibility” and many other web accessibility related terms. The WAVE evaluation tool is used to evaluate nearly a million web pages per year. We hope to continue providing excellent resources.

While I want to point to the excellence and constancy of the staff here at WebAIM, you of course have made our articles and resources popular. Moreover, you also provided translations of many of these into other languages, broadening our impact. A number of our best ideas for resources have come from your suggestions. So please keep those ideas coming!

WebAIM’s discussion forum was started in 1999. In the beginning, we had to respond to ourselves to get any semblance of discussion going. Now, in the last year, over two million distinct e-mails were sent to the over 1000 list subscribers. In 2004, we expanded our WebAIM community and began our monthly newsletter. Then in June of 2006 we began this blog as a way to keep short ideas and opinions flowing. A runaway and unforeseen hit was Aaron’s “History of the browser user-agent string”. If you have never read it, you owe yourself this chuckle.

In the past 10 years we have had the privilege of providing training and technical assistance to thousands of individuals; many of them during site-based workshops at college campuses, governmental agencies, and businesses across the nation. And beginning in 2007, many right in our own backyard as we began to offer 2-day workshops here in Logan, Utah three times a year.

We are also thankful for the businesses, including several fortune 500 corporations, that contract with us for web accessibility evaluation and design work. This keeps us busy and on our toes in the most current technical dialogues.

We have seen shifts in the field over the past decade – web accessibility guidelines and standards refreshed (WCAG 1 to 2; 508 soon to refresh), legal consequences ignored and upheld, and an international climate welcoming and desirous of web accessibility. We continue to focus on our original goal of increasing awareness and knowledge so we all can make the web a better place for everyone. We recognize that you are the reason that we continue to thrive. We are thankful for what you do, and thankful that we are part of your journey. While we reflect over the past decade and on the accomplishments of WebAIM and those we serve, we also look forward to the next 10 years.