While WCAG 2.0 has been used to greatly enhance the accessibility of web content, it is not perfect. Its complexity and rather absurd terminologies, while generally necessary, decrease its approachability (and arguably accessibility) for many people. It is difficult to understand, something ironic considering that “Understandable” is a core principle of WCAG itself. WebAIM has provided a simplified WCAG checklist to help authors get started and to aid in evaluation. Accessibility and technology continues to evolve, and accessibility guidelines must evolve with them.

After three years of implementing and explaining WCAG 2.0, we have identified areas of the guidelines that could be improved or clarified. For a number of reasons, we are unable to participate formally in W3C processes, and we are unaware of any current plans for a WCAG 2.1 or a WCAG 3.0, so we present here some possible changes and improvements to WCAG 2.0, and items that we hope might help you better understand and implement optimal accessibility.

Remove the CAPTCHA Exception

Success Criterion (SC) 1.1.1 (Non-text Content) allows an exception for CAPTCHA, as long as it is identified as being a CAPTCHA and “alternative forms of CAPTCHA using output modes for different types of sensory perception are provided.” If a site provides both a graphical and an audio CAPTCHA, it passes. This, however, continues to exclude users that are deaf-blind, not to mention the difficulties that all users have with CAPTCHAs.

CAPTCHA has failed. Automated processes can now bypass it faster and more accurately than actual users. WebAIM clients, even those in the highly secure financial services industry, are abandoning CAPTCHA. WCAG should do the same by removing it as an exception, or perhaps allowing graphical and audio CAPTCHA for Level A conformance but prohibiting all CAPTCHA at Level AA.

Media Guidelines

“Media alternative for text”

Several of WCAG 2.0′s media guidelines include “…except when the media is a media alternative for text and is clearly labeled as such.” This means that text alternatives are not required if the video is an alternative version of the main text content of the same page (for example, a web page with the text of a speech that also presents a video version of that speech). This, however, is often misunderstood to suggest that if a transcript is provided, then captions or audio descriptions are not required. This could perhaps be clarified to indicate that if the main content of the page provides all necessary content of the associated media, then no other requirements (captioning, transcript, etc.) are necessary.

“Alternative for time-based media”

“Alternative for time-based media” is a confusing term for a descriptive transcript – a text transcript of the audio or video that provides all necessary auditory content (such as identifying laughter or an off-screen explosion) and visual content (such as a list of items displayed in the video that are not presented via audio). We simply use “descriptive transcript” instead and have found is much more easily explained and understood. If a user reads the descriptive transcript, they will get all of the necessary content conveyed in the audio or video.

Audio descriptions and transcripts

Synchronized captions are always required for audio/video content at Level A. Additionally, either audio descriptions (auditory presentation of visual content in the video) or a descriptive transcript is required for Level A conformance by Success Criterion (SC) 1.2.3. Either of these meets the needs of users with visual disabilities. If an author provides a descriptive transcript to satisfy SC 1.2.3, then audio descriptions are required in SC 1.2.5 at Level AA. However, if an author provides audio descriptions to satisfy SC 1.2.3, then a descriptive transcript is not required until SC 1.2.8 at Level AAA. This latter case would render the media inaccessible to deaf-blind users at Level AA, because both captions and audio descriptions are inaccessible to these (and many other) users.

This is all compounded by the fact that if the video does not require audio descriptions (meaning all necessary visual content is presented in the audio of the multimedia), then SC 1.2.3 and SC 1.2.5 are satisfied. This means that for such video (e.g., a talking head), the author is not required to provide a descriptive transcript unless they are seeking Level AAA conformance. In other words, if a page contains only audio, it requires a descriptive transcript at Level A. But if you add a talking head video or simply add the audio to some video content, it doesn’t require a descriptive transcript until Level AAA. This surely is a weakness in WCAG 2.0 that should be addressed.

Recommended restructuring

Confusion and limitations of the current guidelines could be addressed by structuring the guidelines as follows based on the media’s characteristics:

• Level A
  • Pre-recorded audio only – provide descriptive transcript.
  • Pre-recorded video only – provide descriptive transcript or audio description.
  • Pre-recorded audio/video:
    • Provide synchronized captions.
    • If visual content is not presented via audio, provide audio description or a descriptive transcript.
• Level AA
  • Pre-recorded audio/video – provide a descriptive transcript.
  • Live audio/video – provide synchronized captions.
• Level AAA
  • Pre-recorded audio/video – provide audio description, if necessary.
  • Pre-recorded audio or audio/video – provide sign language.
  • Live audio – provide synchronized captions.

This structuring would require audio descriptions or a transcript at Level A, but only if they are necessary for blind accessibility. At Level AA, all pre-recorded video would require transcripts. At Level AAA, video would require audio descriptions, if they are necessary due to visual-only content.

It is with great hesitation that I recommend moving audio descriptions to Level AAA (in WCAG 1.0, they were Level A). While they are the primary and preferred mechanism for providing multimedia accessibility to users with visual disabilities, one must balance their significant expense and difficultly to generate and the fact that transcripts provide equivalent content and are also accessible to a much broader audience (e.g., deaf-blind). Because a transcript will already have been generated in order to provide captioning, it seems more logical that the emphasis should be placed on providing a nearly universally accessible descriptive transcript, rather than on providing less usable and more burdensome audio descriptions.

Contrast at Level A

White text on a white background is Level A conformant. No contrast requirements are present until SC 1.4.3 at Level AA. Adding a minimal contrast requirement (perhaps 2:1 and 3:1 for large text) at Level A would help address significant readability issues that could be found on Level A conformant sites.

Decrease the 200% Text Resizing Requirement

Users with significant low vision rarely resize text in a browser. If a user requires text that is twice the default size, page zoom or a dedicated screen enlarger is and must be used. Designing modern web interfaces to support 200% text resizing is very difficult. This Level AA success criterion typically poses the most significant burden to our clients (often more so than captioning). We strongly recommend that the text resizing threshold be reduced to 150%, with perhaps a 200% threshold for Level AAA conformance.

Clarify Images of Text

Success criterion 1.4.5 requires that if the same visual presentation can be made using text alone, an image is not used to present that text. The possibility of highly stylizing text and page elements with CSS (especially CSS3) begs the question of how one defines “same visual presentation”. For example, a graphical button with rounded corners, a background gradient, and text drop-shadow could be recreated with text and CSS3, but it is not clear if this is required to meet this Level AA success criterion.

While using text is always optimal for accessibility (and for other reasons), Level AA conformance should only require that the graphical text be replaced with true text when readily-available font face styling will suffice. In other words, authors should not be required to implement significant text styling to duplicate the graphical text’s presentation. SC 1.4.9 (Level AAA) already prohibits all presentation of text within images.

Specify Mechanisms to Bypass Blocks

A wide variety of “mechanisms” are available to allow users to bypass blocks of repeated content on web pages. This success criterion would be more meaningful and understandable if it required at least two possible mechanisms, such as:

• a “skip” link
• a consistent heading structure (e.g., main content always begins with an <h1>)
• in-page navigation links
• use of landmark roles
• HTML5 structural elements

“Can Be Programmatically Determined”

WCAG 2.0 uses the phrase “can be programmatically determined” extensively. A wonderful article by Jason Kiss explains this term and its use in WCAG. This term refers to relationships that assistive technologies can make between content and/or markup. WCAG defines it to mean that technologies “can extract and present this information to users in different modalities”, whatever that means.

In most cases, when WCAG 2.0 requires that something “can be programmatically determined”, modern technology can actually do so. But not always.

As an example, if an ambiguous “click here” link is preceded by a descriptive heading, this is allowable at Level A by SC 2.4.4 because the meaning of the link “can be programmatically determined” based on the heading structure. The problem, however, is the word “can”. No modern assistive technology actually implements a method whereby the link is automatically made unambiguous because of this structural relationship. In other words “can be programmatically determined” does not mean “IS programmatically determined”.

This creates a situation where WCAG allows or requires something that does not actually result in any better accessibility. It also presents a situation whereby authors can’t know for sure if their content is actually conformant without knowing if assistive technology CAN do something. And which specific technologies or how many of them must do it before “can” means “can”? This is very akin to WCAG 1.0′s very confusing phrase “until user agents…”.

While supporting documentation attempts to clarify this, it remains a confusing aspect of page conformance. This could perhaps be addressed by more specific details at the success criteria or techniques level that reflect actual assistive technology capabilities, rather than simply suggesting that potential support is sufficient.

Require Keyboard Focus Indicators at Level A

A lack of keyboard focus indicators for navigable page elements – SC 2.4.7 (Level AA) – renders a page nearly entirely inaccessible for the large population of sighted keyboard-only users. This is one of the most significant and pervasive accessibility issues currently on the web (see The Plague of Outline:0). There is no reason why this should not be a Level A requirement.

Remove Parsing Requirement

While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA.

Conclusion

This is not intended to be a criticism of WCAG 2.0. The web is clearly much more accessible because of these guidelines. As future updates to WCAG are considered, and as authors implement these guidelines today, these recommendations might provide some clarity and guidance, with the hope of making the web more accessible for all users. If you have feedback on these recommendations, or have thoughts of your own on WCAG, please comment below.

The table below outlines errors for the home pages of the Alexa Top 100 US sites (excluding porn, content farm, and advertising sites). The WAVE toolbar was used to calculate errors. Because the WAVE toolbar evaluates content after JavaScript is processed, and because WAVE errors almost universally indicate a significant accessibility issue, the number of errors is generally a good indicator of true end user accessibility issues.

Site Data

Conclusion

Care should be taken in interpreting these results. These data should not be used to cast a sweeping judgement on a site. Home pages are often dissimilar to content pages, though these data generally correlate to Karl’s more extensive analysis. Regardless, the fact that an average of 25 errors per home page are present, and that only 4 of the 100 home pages had 0 errors is rather telling. There is much that still needs to be done to improve web accessibility.

In a very simple example, it is Google’s “Did you mean…?” functionality. It’s much of what allows iPhone’s Siri to use loads of data to hopefully figure out what the heck you’re asking it to do.

As an example in the accessibility realm, if a form control does not have an associated label, the JAWS and VoiceOver screen readers will implement algorithms to auto-associate adjacent text to the control. In short, they guess what the label probably is. While this can improve the user experience in many cases, this semantic automation often fails. Even a line break or spanned text can break the current algorithms. And worse, an incorrect label for a control might be read if the layout is complex or different than the norm (such as when labels for checkboxes are placed to the left the checkboxes) .

When computers guess, the results are often not very good. But guessing is usually better than nothing.

Automation and Evaluation

I had switched my primary evaluation platform from JAWS to VoiceOver some time ago because until recently, VoiceOver did not implement semantic automation. It was very literal. If a text box was not properly labeled, it simply identified the presence of the text box, even if there was descriptive text next to it. With the release of iOS5 and Lion, VoiceOver will now auto-associate the adjacent text. When done correctly, this will be very helpful to users, but for evaluation, there’s no way to know if label text is actually associated or if VoiceOver or JAWS is just assuming it should be. And there’s no option to disable this functionality.

This creates a situation where screen reader evaluation and even user testing may not accurately reveal underlying accessibility issues. But this begs the question, if the user agent fixes the issue most of the time, is it really an issue at all?

Automation and Conformance

In order to be compliant with the Web Content Accessibility Guidelines 2.0, you have to implement accessibility. These guidelines don’t address or allow semantic automation. But what if they did? Most of the impactful success criteria could be automated by user agents to some extent:

• 1.1.1 – Alternative text: Image analysis could be performed to determine the content or description of an image.
• 1.2 – Captions and transcripts: Audio recognition could be done to auto-generate a transcript and captions, similar to YouTube’s automatic captioning functionality.
• 1.3.1 – Information and relationships: Headings could be assumed based on text size, length, and location. Form labels could be auto-associated. Table headings could be assumed based on styling and table structure. Lists could be auto-generated when numbers, bullets, sequential items, etc. are used.
• 1.3.2 – Meaningful sequence: The reading and navigation order of content could be based on the visual layout, rather than the underlying markup.
• 1.4.1 – Color, 1.4.3 – Contrast: Browsers could automatically replace colors or increase contrast if they don’t meet certain thresholds.
• 1.4.5 – Images of text: Character recognition could be implemented to replace images of text with true text.
• 2.4.1 – Bypass blocks: A user agent could analyze the document and define navigable page areas based on structure and visual presentation. VoiceOver does this now with auto-webspots.
• 2.4.4 – Link purpose: Screen readers could analyze link context to turn “Click here” into meaningful, descriptive text.
• 3.1.1 and 3.1.2 – Language of Page and Parts: The computer could determine the language of content automatically, or even automatically translate it.

And there’s more. These types of semantic automation would all be very beneficial to users with disabilities, but they will never be as good as authors just doing it right.

Defining the boundaries between what the web page author’s intentions are and what the browser can automatically do for the user is difficult. Should a screen reader automatically perform image analysis on an image that is missing alternative text? Should it do so even though this would present incorrect content much of the time? How would a user know if the screen reader is presenting true page semantics or automated semantics? How can the algorithms be improved to avoid spectacular failures in semantic automation? Etc.

Then Why Bother?

If screen readers automatically and correctly associate form controls for 95% of controls, why bother using label elements? If computers can usually determine table headers or heading structure or video transcripts, etc., then is it worth the effort to do it on my own? Of course the only way to ensure that accessibility is done right, is for authors to do it right. Semantic automation will never be perfect, yet because accessibility is about the human experience, it’s the obligation of the assistive technology to provide the best experience, regardless of the page’s accessibility or lack thereof.

The question is, then, what will ultimately lead to most optimal accessibility? Avoiding semantic automation so that authors are more motivated and required to do it right, or implementing eternally-less-than-perfect semantic automation with the knowledge that authors might never bother to do it right? As with most things in accessibility, the answer is probably somewhere in the middle. What do you think?

Using Dragon

Speech recognition software such as Dragon serves two roles: it converts speech into text and it allows users to navigate through content using spoken commands. It is typically used by individuals with motor disabilities, but may be used by people with other disabilities (e.g., cognitive) or in conjunction with other AT for users with multiple disabilities (e.g., Dragon and JAWS). Speech-to text has little impact on accessible web design, so I will not focus on it in this post. Instead I will look at how Dragon is used to navigate through web content, and what this means for developers.

Design Recommendations

Dragon navigation functions can be divided into keyboard interactions (navigating to links and form controls) and mouse interactions (moving the mouse cursor). Recommendations for each type of interaction are identified below. A few notes/disclaimers first:

• I do not rely on Dragon due to a disability.
• Commands that allow a user to navigate through tabs and windows, search within a page, scroll up and down, etc. have more to do with interaction with the browser than with web content, so they are not addressed below.
• Although Dragon supposedly "supports" Firefox, I had a great deal of difficulty using Dragon in Firefox and ended up relying on Internet Explorer 9 for all of my testing.
• Nuance has also created Guidelines for Speech-Accessible HTML (PDF).

Keyboard Navigation

Links

• Do not disable visible keyboard focus indicators (by default, a dashed line around focused links). Users may navigate through links and form controls by saying "Tab", but it is very difficult for the user to access these links if they cannot see which of the links currently has focus.
• Ensure that the visual order and tab order of content is the same – typically navigation first, then left to right, top to bottom.
• If the link is an image, alternative text should match the text in the image. For example, if an image displays the word "Continue" visually, the user will probably say, "Link continue" to activate the link. If the alternative text does not match the text that appears visually the link will not be activated.
• Use unique link text, when appropriate, especially if the links go to different pages. While the user can select from multiple links that contain the same text, it requires an additional step and may be more confusing for some users.
• Avoid starting links with generic text like "click here", "read more", "learn more", "link to", etc.

Forms

• Use form labels. A user can navigate to a specific form control by saying the label name (e.g., "click First Name"). This process becomes much more difficult if labels are absent. If form labels are not correctly associated to their controls, Dragon will try to guess the correct label based on proximity, with varying success.
• Use the appropriate form control. Users can navigate to form controls based on the control type. A user may try to submit a form by saying "click button", but if the button is not a true button or is an image that uses JavaScript to submit a form, nothing will happen and the user will have to find a different way to submit the form.

Mouse Navigation

Dragon can also emulate mouse interaction. While there are several commands that allow you to do this, my favorite was the MouseGrid. Upon saying the words "MouseGrid", a 3 X 3 grid appears on the screen, with each region given a number from 1 to 9. The user says the number closest to the link that needs to be activated with a mouse, which will cause another 3 X 3 grid to appear. The user continues this process until the grid is small enough that the user can click on a mouse-dependent element on the page, such as an image that uses JavaScript to submit a form, like a button. For example, to return to the homepage on this page (by clicking on the logo), a user would say something like "MouseGrid, 1 [moving the mouse to the upper left corner], 5 [moving the cursor to the center of this area], click". MouseGrid can also be used to quickly navigate to a link that cannot be activated using the link text, such as a linked image with no alternative text.

I found that being able to replicate a mouse click was very handy, but it was a very time consuming process and had limitations.

• Avoid content that requires hovering with a mouse (e.g., dropdown menus). They may be difficult or impossible to access.
• Make clickable items sufficiently large. A small clickable target, such as a tiny radio button or image, may be very difficult to access with the MouseGrid. If checkboxes and radio buttons are properly labeled, the user can speak or click on the label, not just the control itself.
• Make sure clickable items look clickable. It was frustrating to activate something with my cursor only to discover that it could not be clicked on.

Shortcomings of Dragon

Although Dragon is a very capable program, I found a couple issues that made using Dragon much more difficult:

• It appears that Dragon recognizes the title attribute on all links and form controls, including images with alternative text and form controls with labels. This can sometimes be frustrating, especially if multiple elements have duplicate title values. Dragon should approach this issue the same way it is approached by many assistive technologies—only use the title attribute if there is no alternative text or label present. This is another reason that the title attribute should be used sparingly.
• When navigating very large pages, Dragon sometimes displays the following message: "Voice commands were not generated for some links; too many links on page". This is because dragon only analyzes the first 200 links and form controls on the page. Links beyond this limit are not accessible by speaking the link text, but they are still accessible through MouseGrid. Form controls beyond this limit cannot receive dictated text, a much more significant issue. While Nuance offers instructions on how to increase this limit (PDF), I would guess that very few Dragon users know this. It may be impossible to account for this limit on very complex pages, but the problem can sometimes be addressed by removing redundant links, or by combining duplicate links (e.g., a product image and the adjacent text description) into a single link.

Is testing with Dragon Necessary?

The question of whether testing with Dragon should be part of developer testing is a difficult one. While we at WebAIM will probably use Dragon for testing of mission-critical pages in larger evaluations, it is not practical to expect most developers to test with Dragon. The reality is that the cost of Dragon Premium can be high (close to $200), and the purchase of a high-quality headset is usually necessary as well. Training Dragon can also be time consuming, though this is less important if you are not using Dragon for dictation.

While it is important to consider the needs of users who rely on speech recognition software, these needs can probably be addressed without actually testing with Dragon. Almost all of the principles identified above can be detected with WAVE or through basic keyboard testing. If you are interested in trying speech recognition without purchasing Dragon, less feature-rich speech recognition software is built into the Windows and Mac operating systems.

Next Up: Contrast

Next I will explore the high contrast options within the operating system. This should be much simpler than learning ZoomText or Dragon. Look for a write-up soon.

Rocket Surgery Made Easy

I spoke at the Plain Talk conference last week where I heard presentations on usability testing from Steve Krug and Nicole Burton. Steve’s book, Rocket Surgery Made Easy, proposes a basic approach to usability testing wherein frequent (probably monthly), simple usability evaluation sessions are conducted with three average users. A facilitator asks questions and presents tasks to help the user identify the few most significant usability issues, which are then (hopefully) fixed before the next test session.

The power of the Rocket Surgery approach to usability testing is that it focuses on the broad user experience. Accessibility user testing typically does just the opposite. It is used to identify instances of inaccessibility – poor alt text here and a missing label there. Fixing all significant instances of inaccessibility and non-compliance still might result in a poor experience for users with disabilities – something often a result of the entire site content/interaction or a combination of many small issues, rather than glaring WCAG failures.

When users with disabilities are involved in effective usability testing, such as the basic, low-cost approach Steve recommends, they will help address the overall accessibility and usability of a site, and will still be able to identify specific accessibility issues.

Gotchas

While general user testing can be conducted very early in the design process, accessibility testing will likely work better on a site where some accessibility has already been implemented – certainly any WAVE errors addressed, a WCAG checklist reviewed, etc. A usability testing session with a screen reader user, for example, might be very short and ineffective when you realize that your fancy, yet totally inaccessible interface results in no content being read. A lesson learned, for sure, but nothing as valuable as having this user describe their screen reader interactions on a more polished site.

Be careful – while people with disabilities are good at finding accessibility issues, if something is inaccessible, they might not be able to identify it because it’s inaccessible. Unlike usability issues, accessibility issues are often caused by underlying markup or compatibility issues, making them more difficult to identify. You’ll probably want someone versed in accessibility and assistive technology to monitor or facilitate the usability session.

You’ll usually want the users to use their own computer systems, particularly if they are using assistive technology. Recording and monitoring the session will still be possible – even if the user is remotely located.

Should I Stop Doing Accessibility User Testing?

Steve notes in his book, “There’s no question: a good usability professional will be able to do a better job of testing than you will.” This also applies to accessibility. WebAIM, and other experts, are very good at this type of thing. Accessibility and usability testing are both vital, regardless of who does it or how it’s done. If you want to conduct the testing yourself, a low-budget, easy to facilitate, highly effective usability test that includes individuals with disabilities will result in more useful feedback and a more accessible web site than conducting distinct accessibility user testing.

Does it matter how accessible content is, if nobody ever finds it?

Web accessibility and search engine optimization (SEO) are both about getting relevant content to users. Accessible content and search engine optimized content are both machine readable. Search engines and assistive technologies (such as screen readers) are quite similar. In many ways, search engines are deaf, blind, use only a keyboard, and have limited technical abilities. Both rely on content structure, semantics, and functionality to either present content to users or determine the relevance of content.

Accessibility and SEO Magic

SEO has always had an element of what I call “voodoo magic”. It involves guessing or deducing what algorithms a search engine might use to determine the relevance of certain content, then implementing content strategies that best utilize those supposed algorithms. Fortunately, web accessibility has more straightforward guidelines – though a fair amount of voodoo magic is still required to get content to actually work correctly across browsers and assistive technologies. Occasionally the recommendations of SEO “experts” and accessibility “experts” have been at odds; implementing a tactic for SEO would be detrimental to accessibility, or vice versa.

In the 10 years I have been working in the web accessibility field, I have seen SEO and accessibility align more closely. There is now significant overlap between these two fields. Interestingly, SEO has lost most of its “black hat” techniques and has evolved to align more with accessibility, which has changed very little. This, I suppose, provides some validation to long-standing accessibility principles and their intent on making the web a better place for everyone.

Keyword stuffing – using keywords in portions of the page that would not typically be noticed by most users (such as alternative text or title attributes values), but that would be identified by search engines – is a good example of “black hat” SEO. This ‘hidden’ content often isn’t – it may be read or made available to users with disabilities resulting in confusion and poor accessibility. Fortunately, search engines have progressed and now penalize such tactics. SEO, like accessibility, now advocates proper, descriptive alternative text and advisory title attributes that are accurately descriptive of their related content. These are used by search engines to help determine the content of images.

SEO and Accessibility Alignment

The list of accessibility and SEO practices that are closely in alignment include:

• Using proper alternative text for images
• Providing a clear and proper heading structure and avoiding empty headings
• Providing descriptive link text (i.e., avoiding “click here”)
• Ensuring page titles are descriptive, yet succinct
• Not relying on JavaScript for things that don’t need it
• Avoiding mouse dependent interaction
• Using standard web formats when possible
• Providing transcripts and captions for video
• Identifying the language of pages and page content
• Allowing multiple ways of finding content (e.g., search, a site map, table of contents, clear navigation, etc.)
• Using text instead of images when possible
• Providing useful links to related and relevant resources
• Ensuring URLs are human readable and logical
• Presenting a clear and consistent navigation and page structure
• Avoiding CSS and other stylistic markup to present content or meaning
• Defining abbreviations and acronyms

Of course content is king, in both accessibility and SEO.

HTML5, Accessibility, and SEO

HTML5 provides the following improved semantics that will increase both accessibility and search engine accuracy:

• <figure> and <figcaption> for associating images and descriptive text.
• <nav>, <header>, <footer>, <article>, and <aside> for better identifying significant page areas. ARIA provides even enhanced functionality here (especially in the notably missing identification of page main content).
• <details> and <summary> for associating related content.
• Associated <track> elements with <audio> and <video>.
• Microformats, RDFa, microelements, <time> and many similar features can provide useful metadata and functionality.

I believe that HTML5 will further bring SEO and web accessibility into alignment.

Off-screen Content

SEO advocates often have concern over the accessibility technique of using CSS to hide content off-screen. This technique allows useful content to be presented to screen reader users. This should, of course, be used sparingly and only in cases where the content makes sense visually, but additional content may be necessary for users that cannot see the visual presentation. While keyword stuffing in hidden content was once part of the “voodoo magic” of SEO, it is now verboten. Search engines can inflict harsh ranking punishments on pages that are found to be using deceptive or malicious tactics.

Despite these concerns, rest assured that the proper use of off-screen content will not impact search engine rankings. We have received confirmation (unofficial, of course) from Google that such practices are perfectly acceptable, so long as they are not deceptive or malicious. Perhaps the strongest indication that this is true is that the first link on the Google.com homepage is hidden using the off-screen technique WebAIM has always advocated.

SEO + Accessibility = Win!

There is much evidence that suggests that accessibility not only supports high search engine rankings, but that Google may actually favor pages that have strong implementations of accessibility. This is, of course, difficult to prove. I do know that the WebAIM site, which we have tried to keep highly accessible, has certainly been highly favored in search engines for accessibility related terms despite implementing very few SEO-specific techniques.

Good accessibility and good search engine optimization is a great combination for content authors and end users.

My preferred configuration

I am quite nearsighted, so I decided the best way to evaluate a screen magnifier would be to remove my glasses. With my glasses off, I found that my preferred configuration included the following settings:

• Power: 4X magnification. I would really like a 3.5X magnification option.
• Type (part of the screen that is enlarged): Usually full. During the first few days, I spent a great deal of time trying out these different views, including dual monitors, but I found I like to devote the entire screen to magnification.
• Mouse Pointer: Large yellow.
• Color scheme: Normal. I find the inverse color scheme easier on the eyes, but images, especially images of people, look too strange.
• Cursor: None.
• Focus: None. While doing keyboard-only testing I find red outline helpful.
• Reader: On, surprisingly. I had not planned on using the reader feature, but I find the constant narration actually makes things more usable.

Accessibility thoughts and recommendations

I am well aware that a few weeks experimenting with a screen magnifier does not make me an expert, and that some of the difficulties I experienced were due to my lack of familiarity. Still, I feel I gained valuable insights. I have listed a few web accessibility recommendations below.

• Ensure adequate contrast. As expected, it is harder to read text with low contrast. Instances of light gray text are very difficult to read. Sometimes I have to increase the magnification above 4X to read text with poor contrast.
• Use true text when possible. True text is definitely easier to read than text in images, but I am surprised to find that in most cases where text is used in images, the images remain fairly readable, even at high magnification. I think this is because I am not able to see the pixels as clearly (no glasses), so the otherwise jagged text is still smooth and readable. When the default color scheme is changed, text in images sometimes becomes very difficult to read, especially when the background included a gradient. I had not previously considered this situation. It provides an additional reason to avoid text in images when possible.
• Use a proper heading structure. This can definitely enhance accessibility, especially on pages that are content-heavy.
• Use good content separators such as whitespace or color change. Whitespace is helpful, but I sometimes get "lost" if a page has too much whitespace between sections. I assume that a page or section has come to an end when it has not. I find it easier to navigate through pages that use color and other non-whitespace separation between page sections.
• Provide a flexible page layout. I usually keep my window at about 800-900 pixels wide. This offers a good readable line length without breaking too many page layouts. While most pages display content well, some pages display a horizontal scroll bar (which I can’t see because it is not onscreen) or have content sections that overlap at this width. It seems that many of these problematic pages have a three-column layout (sidebars on the right and left side).
• Use succinct, descriptive link text. Long links with filler words (e.g., "Click here for more information on…") often require panning or scrolling.
• Be careful with rollover menus. These are kind of a mixed bag for accessibility. On one hand, they occupy less visual space, making it easier to see content on the page. On the other hand, the menu itself is often very difficult to navigate. When creating rollover menus, avoid menus that are too long or that contain more than one level of links.

Other insights/thoughts

• While I have typically used the term "screen enlarger" to refer to this type of software, it seems that "screen magnifier" is the more common term. I will try to use this term from now on.
• 2X magnification (a WCAG recommendation for enlarging all content as well as text) is actually quite a bit bigger than it might seem. Many (probably most) sites on the web do not support text resizing to this level. I cannot image a situation where a user would double text size without using a screen magnifier to enlarge other content on the page as well (text in images would probably be unreadable to this person). What I can imagine is a user who resizes text to a more moderate size (say 1.5X) in conjunction with a screen magnifier. While the WCAG recommendation for text resizing is a good goal, I think that an otherwise highly accessible site that supports 1.5X test resizing is in a pretty good place.
• After returning to my normal resolution the screen seems small and difficult to read for five minutes or so.
• Screen magnifiers and projectors don’t play nice. The last time I tried to demo ZoomText in a presentation, it blue-screened my computer.
• I actually find using a screen magnifier kind of enjoyable at times, especially at the end of a long day. It is nice to remove my glasses and "relax" my eyes a bit. This probably suggests that I need to improve my screen location and resolution.
• It took me weeks to realize that the "logo" in the ZoomText window was actually a button that would allow you to quickly enable and disable ZoomText. I guess it pays to read the manual.
• I have a very difficult time typing more than a few words with ZoomText enabled. There is something about only being able to read a few lines of text that makes it very difficult to compose my thoughts. This is the one area where I couldn’t keep from cheating during my "final exam" (a full day using ZoomText).

Importance of screen magnifier testing

This was a very worthwhile experience and I feel that I learned quite a bit. I plan to continue to use ZoomText and demonstrate it in trainings (assuming I ensure it works with the projector beforehand). However, as valuable as this experience has been personally, I still think the built-in browser zoom and text resizing functions are adequate for most accessibility testing. These provide a comparable experience with no cost and little-to-no training. If I were to add an additional recommendation, it would be to test inverted color schemes, but this is something that can be done at the level of the operating system.

Next up: Dragon

Next on my list is Dragon NaturallySpeaking. Look for a similar post on Dragon in the next month or two.

It’s important to note that this technology preview is far from completion. We chose to release this preview for a few reasons. First, our lead software engineer, Aaron Andersen, is leaving WebAIM this week for a new position. He, along with other WebAIM staff, have worked tirelessly on updating the core WAVE5 functionality and we wanted to share his work before he leaves. We wish Aaron the best in his new endeavors. Second, we want to share our general vision for WAVE5 with the community. We believe the sidebar approach will allow much easier and more powerful evaluation. And finally, we want to solicit feedback about the general direction WAVE5 is going (we’re aware of bugs and will certainly be doing additional bug testing, so bug reports are less necessary now).

A few important notes on this preview release:

• Again, this preview is NOT complete. There are many known bugs, some things just may not work at all, accessibility is not complete, and it’s quite rough around the edges. Thus, it is a preview release, not even an alpha release… yet.
• Not all of the new, updated WAVE logic, icons, and rules have been implemented yet. We have entirely restructured many of the rules to provide more accurate and useful evaluation feedback. These will be available in a later beta release.
• Several new reports and views will be available in the future. These will allow new types of evaluation and customization of the icons you see.

Please check out the WAVE5 technology preview at http://five.wave.webaim.org/.

With all the time I’ve spent using screen readers, I wonder if my view of accessibility is a bit screen reader-centric. I’m not suggesting that I ignore other accessibility issues. I test for color contrast, enlarge content, check keyboard accessibility, look for visible focus indicators, etc. These principles and activities are part of our trainings as well. But most of this testing and training is done in the browser or by using tools like WAVE or the Web Developer toolbar. The truth is, with the exception of screen readers, I spend very little time using assistive technologies.

The experiment

In the next few months, I plan to familiarize myself with other common assistive technologies (AT) and share some of my experiences. First on my list is a screen enlarger or magnifier, probably ZoomText. I plan to spend a week or so just playing around and getting used to it. During this time, I will also search for articles, tutorials, forums, etc. that might help me get up to speed. Next I will try tasks, such as checking and composing email or ordering something on Amazon. My "final exam" will be a full day relying on the assistive technology. I am quite nearsighted, so I will probably remove my glasses to keep me from cheating. This will probably be more difficult than it sounds. I am sure it takes much longer than a few days to become proficient with any assistive technology.

At the end of the experience, I will write a blog post recapping my experiences and possible frustrations, with a focus on practical accessibility recommendations that I discovered or that were reinforced during my experience. If the experiment is a success, I may follow up with other assistive technologies or configurations every month or so. A few come to mind:

• Voice-controlled software, such as Dragon Naturally Speaking
• Windows high contrast mode
• Keyboard-only, maybe using some kind of AT

I am open to recommendations, but will probably limit this to AT that is relatively easy to learn, and will yield valuable accessibility recommendations.

As I embark on this experiment, my goal is not to promote myself as an AT expert, or as a spokesman for those with disabilities. Spending a few weeks using ZoomText is not a substitute for a lifetime of experiences of individuals who rely on a screen enlarger for their daily computer use. My primary goal is to acquire and pass on a better understanding of how we can make web content more accessible for all users, and how these tools can be used in our own training and evaluations.

Is AT proficiency necessary?

Am I suggesting that every website must be tested with a dozen unique assistive technologies before it can be pronounced "accessible?" No. That would be a step backward. I do not want to return to the days of "until user agents…." any more than web developers want to go back to testing for Netscape 4. WebAIM has always advocated a principle-centered approach to accessibility, and we know that encouraging developers to follow good accessibility principles is challenging enough. However, I think personal experience with some common, but often overlooked, assistive technologies could help me, and hopefully others, better learn and address the diverse needs of users who benefit from accessible design.