WebAIM Blog

The focus of web accessibility is often on web development – the things that happen in HTML, CSS, or JavaScript after a site has been designed visually. Optimal accessibility should start much earlier, as part of the visual design process. We have created an infographic that highlights a few important principles of accessible design. Select the image to view the full infographic and text version.

What is the value of finding content if the user experience and accessibility of that content is poor?

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.

As mentioned in a previous post, I recently decided to spend some time becoming more familiar with a few common assistive technologies, starting with the screen magnification software ZoomText. I have shared a few of my experiences with ZoomText below.

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.

A little over a year ago, we announced the beginning of development for WAVE5, the fifth major revision of WebAIM’s popular WAVE web accessibility tool. At the time, we were hoping to have it ready to release by the end of 2010. That obviously didn’t happen, but today we’re pleased to announce the availability of the WAVE5 technology preview.

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/.

Like many web accessibility folks, I spend quite a bit of time using screen readers. I use them when conducting accessibility evaluations and when training others. Hardly a week has gone by in the last few years that I haven’t spent some time using a screen reader. They are unique programs that deserve special attention.

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.