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.

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.

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.

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.

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.

Be sure to check out the results of our previous survey as well.

While the full details are available, here are a few findings we found interesting, surprising, or relevant:

• JAWS continues to be the most popular screen reader (75%). Window Eyes use remains at 24%. However, NVDA (26%), System Access (23%), and VoiceOver (15%) all saw tremendous increases in usage in the 10 months since our previous survey.
• 83.6% of respondents updated their primary screen reader within the last year.
• 50% of respondents (53% of respondents with disabilities) use a screen reader on a mobile device.
• 75% of respondents do not have javascript disabled in their primary web browser.
• 42% of respondents did not know that ARIA landmark functionality even exists.
• CAPTCHA, Flash, ambiguous links, poor/missing alternative text, complex forms, and poor keyboard accessibility are cited as the most problematic items on the web
• YouTube (51.3%) and blogs (47.7%) are the most commonly used social media tools, with LinkedIn (13.4%) and MySpace (9.0%) rarely used.
• The majority of respondents found blogs, Facebook, Twitter, MySpace, and YouTube to be accessible and most reported LinkedIn as being inaccessible.
• 62.6% say it is somewhat unlikely or very unlikely for Flash content to be accessible to them.
• Headings are the primary mechanism (50.8% of respondents) for finding information within a page.

Please take some time to review the survey results. We will be posting observations and details from the survey’s open ended questions in the near future. If you have questions, want us to analyze a particular piece of data, or have recommendations for a future survey, please contact us or leave a comment below.

That’s the most accurate way that Google Wave (not to be confused with the original WAVE) accessibility can be summarized. It must be disclaimed that this is a very early preview release of Google Wave, and functionality and accessibility will certainly be improved along the way. Still, it is rather disheartening to see no attention paid to accessibility. For example:

• Alternative text is not provided for any images.
• Background images are used to convey content.
• Roles, states, and other accessibility properties are not defined.
• There is no document or heading structure or semantics. None! Not even a list!
• Form elements do not have labels or titles.
• Keyboard focus indication is hidden, making keyboard navigation nearly impossible.
• Most interactive elements are not in the tab order or do not respond to keyboard activation.
• Keyboard focus is often trapped, requiring the page or browser to be closed to resume keyboard navigation.
• The application becomes unusable and unreadable when text size is increased only slightly.

… and I think you get the general idea. One positive point – the welcome and introductory videos are captioned.

Possibilities

Despite it’s rudimentary nature, e-mail continues to pose a relatively significant accessibility issue to users with disabilities. This is primarily due to its dual-threaded nature – meaning that messages can have replies, but the content of replies often takes an entirely different form. The response text of a particular e-mail might be top-posted, bottom-posted, or intermingled throughout the original message. This complexity is compounded by the fact that participants can join or leave the e-mail discussion at any point.

Google Wave does a wonderful job of addressing these issues by presenting the conversation in a way that does not rely on threads or quoted replies. The entire history of a conversation can be viewed or replayed. Conversation participants can join or leave along the way without losing context, history, or content. Additionally, Google Wave adds real-time interactivity and collaboration to the communication.

In short, the potential for Google Wave to streamline and enhance communication for people with disabilities, especially screen reader users, is great. Could Google Wave be made accessible? I believe it could be. I would never advocate that accessibility constraints should limit innovation – indeed many of the most accessible technologies now available started as accessibility black holes. Of course it is always easier and better to implement accessibility as part of innovation, something clearly lacking in this case.

With ARIA and modern-day user agents and screen readers, Google Wave can be made accessible and become a powerful tool that ALL users can enjoy and benefit from – and people with disabilities have particular need for such enhanced communication tools. With a bit of education or guidance, and typical Google ingenuity, Google Wave has great potential to not only be a wonderful tool, but a wonderfully accessible tool.

(Contact the author through Google Wave at jaredsmith36459@googlewave.com)

As a follow-up and update to the original WebAIM Screen Reader User Survey, we are happy to provide an updated survey. By completing this survey you will help inform development choices for those creating accessible web content. All screen reader users, even those that use screen readers only for evaluation and testing, are invited to participate.

WCAG 2.0 requires that the foreground and background colors have a 4.5:1 contrast ratio at Level AA and a 7:1 contrast ratio at Level AAA. You can use our contrast checker tool to determine what the ratio is between any foreground and background color.

WCAG 2.0 also requires (at Level A) that color not be used as the sole method of conveying content or distinguishing visual elements. They further define this requirement for links with Technique G183, which states, “Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them.” This means that if you do not underline your links (or provide some other non-color designator for links), that the links must be sufficiently different in contrast from the surrounding text.

So if you combine these two requirements, in order to be Level AA conformant, your page must have all of the following:

• A 4.5:1 contrast between the non-link text color and the background.
• A 4.5:1 contrast between the link text color and the background.
• A 3:1 contrast between the link text color and the surrounding non-link text color.

In other words, your link color has to be significantly different from the background color AND the surrounding text color, which also has to be significantly different from the background color.

Meeting these requirements

If you start exploring this, you’ll find that this requirement leaves only a small window of available page and link colors. For example, if your page has black text on a white background and you use the standard blue color for links, the link color must be between approximately this color of blue (#6e5eff) and this color of blue (#531fff). Any lighter or darker and it will not have sufficient contrast to the adjacent black text or to the white background, respectively.

And if your text/background colors aren’t pure black and white, this significantly narrows or eliminates the window of colors with sufficient contrast.

Link states

This becomes more complicated if you want to provide various link states (hover/focus, visited, active) colors. If you go with the traditional blue, red, and purple colors for link states, each of these three colors would have to fit into the narrow window of available contrasts.

Some testing shows that this is possible… barely. The following colors for link states meet these requirements for a black on white page:

Normal: #3344dd
Hover/Focus/Active: #bb1122
Visited: #884488

But there’s not much wiggle room – if you change any of these colors much you’ll break either the 3:1 requirement to black or the 4.5:1 requirement to white. The W3C does provide a list of web-safe colors that fit within these contrast requirements. But if your page doesn’t have black on white (or vice versa), it quickly becomes impossible to get any one color to work, let alone two or three colors for the various link states.

Level AAA conformance

To complicate things further, if you’re looking for AAA conformance, which requires foreground/background contrast of 7:1, you have virtually no choice in the color combinations. You must have black text on a white background and your blue/red/purple colors must be VERY close to #3344dd, #b50010, and #804180. These work out exactly to 3:1 to black and 7:1 to white, the very minimal levels allowed.

Hover/focus state requirements

It’s important to note that according to G183, focus/hover states for links must have a non-color designator. This typically means that you would add the underline style to the link when it is hovered or tabbed to. This is a Level A requirement.

Because links that have current focus or are being activated will be visually apparent through the non-color designator, not to mention the fact the user has manually focused them, I believe the 3:1 contrast rule does not (or should not) apply to the hover, focus, or active states. In other words, it’s acceptable to have the hover, focus, and active link be very similar in contrast to the surrounding text color because the user must have done something with the link to activate that state AND the non-color designator must be present if they’ve done so. The 4.5:1 (or 7:1) contrast requirement to the background does apply to all link states.

Summary

Because of the WCAG 2.0 contrast requirements, if you don’t underline your links, there’s not much flexibility if you want to be Level AA, let alone Level AAA conformant. WCAG recognizes that meeting these contrast requirements “is not the preferred technique to differentiate link text”. Of course the easy solution to this is to simply underline links in their default state. Interestingly, underlined links can be the exact same color as their surrounding text, though this is far from optimal.

The contrast requirements for non-underlined links is a Level A guideline, which might suggest that they are of more importance than having high levels of contrast for non-linked content (which, interestingly, is only addressed at Level AA and AAA – white text on a white background with white underlined links is seemingly allowed at Level A). Regardless of conformance, it is vital for accessibility that there be good contrast for text and that links be discernible.

So, are the WCAG contrast requirements too stringent and inflexible? Or is it optimal for accessibility for WCAG 2.0 to limit non-underlined links to this narrow contrast window?

This Friday, July 24^th, at 4:45pm, President Obama will indicate his intention to sign onto the United Nations Convention on the Rights of Persons with Disabilities (CRPD). The document will likely be delivered to the UN on July 30^th. This is a historic occasion—one that will positively affect web accessibility here in the U.S.

Many WebAIM readers are familiar with the impact that this UN treaty will have on accessibility (We have posted on this topic before). The CRPD embeds requirements for accessible information throughout the document and it includes an entire section (Section 9) devoted to accessibility. The authors of the CRPD view the work of accessibility as an important mechanism for a “civil society” to affect true social inclusion.

Once the U.S. is a signatory to the CRPD, we will begin the long process to align our national laws and policies to that of the UN treaty. There will be much work ahead for those of us who advocate for accessible web content. We in the U.S. have waited a long time for this moment. Although our internal ratification process may take some time, let us give thanks that our nation has begun to join 140 others who have already signed onto the CRPD. As the 19th anniversary of the ADA draws near, this is a fitting step toward providing persons with disabilities with important extensions of their civil rights.