Good Examples of Accessible Web Sites

Last week Steven Faulkner blogged about real world ARIA landmark use. He analyzed the HTML home pages of the top 10,000 websites, looking for ARIA landmark roles. Among his findings, he discovered that 130 of these pages are using role="main".

I'm often asked for good real-world examples of accessible websites, and this seemed like a perfect starting point for identifying some promising practices. So I spent a couple of hours over the last few days opening up each of those 130 pages and giving them my 10-second web accessibility assessment, which goes something like this:

  1. Use the Outline button on the WAVE toolbar to see if the web page has a halfway decent, logical heading structure. I was pleased to see that each of the 130 sites used HTML headings, but several sites had heading creep. Screen reader users benefit tremendously from good heading structure, but if a web page has too many headings, this offsets the benefits, and some of these sites have several dozen headings. If everything is a heading, nothing is a heading.
  2. Again using the WAVE toolbar, check for Errors, Features, and Alerts. If there are many errors, I assume this page will not serve as a good example, and stop checking. If there are only a few errors (e.g., fewer than five) I'll check those errors and might be forgiving if they're relatively minor and are offset by good accessibility in other areas.
  3. Try tabbing through the page. If there's no visible indication of focus and it's impossible to tell where I am on the page, this page will not serve as a good example.
  4. If the page includes video content, try playing a video to see if it's captioned. If it isn't, this page will not serve as a good example.

If a page passes the above tests, it's worth a closer look.

It's great that at least 130 of the top pages are using ARIA landmark roles. However, of all these pages, only eleven passed my 10-second accessibility assessment, and of those only seven survived the cut to be featured in this blog post. With that, here are seven pretty good examples of accessible websites...

CouchSurfing.org

Screen shot of CouchSurfing.org

I didn't create an account to explore this site beyond the home page, but I like what I see on the home page. There are a few areas where the page could be improved, but here are the features I'm impressed with:

  • Excellent heading structure
  • Clean, simple interface
  • Video on the home page is captioned/subtitled in 14 languages..
  • Labels on most form fields. The lone exception is birthdate, which is divided into three fields, only the first of which has a label. I consider this a minor problem, since the birth day and birth year fields are select boxes with pre-defined options, so screen reader users aren't likely to have difficulty understanding this series of fields.
  • A language picker at the top of the page. When users select a new language, the page is reloaded with all text translated. The lang attribute on the <html> element also changes to reflect the new language, so screen readers will pronounce the text correctly. This is a very cool feature, and makes the site accessible to millions of people who would otherwise be excluded due to language. However, it's a little buggy. Selecting some of the languages (e.g., " Slovenčina") does not result in translated text on the home page, but does result in a changed lang attribute, so screen readers that support the selected language will pronounce the English text using the new language's speech engine, which is not likely to be intelligible.

U.S. Government Sites

It's not surprising to see U.S. government sites on this list, since they're required to be accessible via Section 508 of the Rehabilitation Act. The best of the U.S. government sites in the sample are the Center for Disease Control and Social Security Administration sites.

Screen shot of the CDC site
Screen shot of the SSA website

The accessibility of these sites is very similar. Both sites include:

  • A full set of ARIA landmark roles, including (in various places) banner, main, navigation, search, complementary, and contentinfo.
  • Good heading structure. On each site, the home page skips H2, but it's used on other pages in the site and it's arguably more important to preserve consistency throughout the site than to sacrifice that consistency in order to have a perfect logical heading structure on any one page.
  • Both sites include hidden same-page links at the top of the page for skipping to particular content. The CDC site includes five of these links, roughly corresponding with each of the landmark regions. These links become visible when keyboard users tab into the page. These links may ultimately be unnecessary if browsers support navigation by headings or landmarks. Screen readers already provide this support, but until browsers do so natively, non-mousers with eyesight can benefit from skip links like the ones on these government sites.

Both sites support multiple languages (English and Spanish), and both include lang="es" on the <html> element of the Spanish pages. However, on the CDC site, in addition to lang="es" the <html> element has xml:lang="en". This potentially sends mixed messages to screen readers (is this web page in Spanish or English?) JAWS 13 seems to honor lang rather than xml:lang but I don't know about other screen readers.

USA.gov

Screen shot of USA.gov

This site, the U.S. Government's official web portal, deserves its own entry for its effort in creating an accessible slideshow. Many of the sites in the sample had slideshow widgets, but this is one has some accessibility characteristics that most others don't have:

  • It is fully controllable by keyboard. Users can tab into it, visibly see which control has focus, and execute that control by pressing enter.
  • The slideshow auto-advances, which can be distracting for some users, but there's a pause button so users can prevent the slides from advancing, and other buttons so users can control the slides manually.
  • The slides are hidden with display:none and made visible with display:block, and each is marked up with aria-live="polite" so when it becomes visible, screen readers will read the new slide only when it's convenient for the user (i.e., they won't interrupt if users are actively reading something else).

Coincidentally, the day I evaluated this site they were promoting Autism Awareness Month. That's cool, and I confess it may have biased my assessment, although I really do think USA.gov has done a great job with their accessibility.

Canada.ca

Screen shot of the Canada.ca home page. All content appears in both English and French

Not to be outdone by their Southern neighbors, the Canadian government site is highly accessible. The home page is a simple page, beautiful in its perfect symmetry between English and French. The default language as specified on the <html> element is English (lang="en", hey they had to pick one) but all French content is marked up with lang="fr". It's actually quite pleasing, and very Canadian, to listen to this page with JAWS as it alternates between the two languages.

Screen shot of the English language site on Canada.ca

Once a user selects their preferred language, the content inside the site features several exemplary features:

  • Extensive use of ARIA, not just for landmarks but for communicating roles and properties of other content as well. This is particularly important for making dynamic content accessible to screen reader users.
  • A slideshow that has comparable accessibility to that on the USA.gov site.
  • A keyboard-accessible dropdown menu that can be navigated not just with the tab key, but with a full keyboard model including tab, arrow keys, and escape. For more information about why this a good thing, see my recent blog post on Accessible Dropdown Menus.

Service-Public.fr

Screen shot of service-public.fr, the French government website

Not to be outdone by either the USA or Canada, the French government site has perfect heading structure, a full set of "Aller au" ("Skip to") links, and a 100% pass rate using the WAVE accessibility checker, which means (among other things) all images have alternate text and all form fields have labels.

Another feature that I like on this site is the Écouter button:

A play button on the French government website, with label Écouter

If the user selects this button, the page is read aloud while text is highlighted. This is powered by ReadSpeaker, which I think is a really cool product. It provides improved accessibility to a vast audience of people who might not otherwise have their own assistive technology, such as people who are not native to the language of the page, or people with dyslexia or other reading challenges.

Mozilla.jp

Screen shot of Mozzila.jp website

Mozilla Japan is the only Mozilla site to appear in the sample, but I could easily feature almost any Mozilla site in this review. The Firefox page in English has similar characteristics:

  • A clean, simple interface
  • Good heading structure
  • A keyboard-accessible dropdown menu that includes support for arrow keys in addition to tab.

My only beef with the Mozilla site is that wherever video is shown (e.g., Firefox Flix) they provide subtitles in non-English languages, but don't provide English captions. So Mozilla's videos are accessible to people who read Ligure and Shquip, but not to Deaf or Hard of Hearing folks who need English captions.

Where are all the university sites?

Since I work in higher education, I was excited to see four university sites within the 130-site sample. These sites (Penn, Harvard, USC, and NCSU) all have reasonably accessible sites, but each had problems that regretfully kept them off my final list.

Penn in particular nearly made the cut because I really like their keyboard accessibility. It amazes me how few sites provide visible indication of keyboard focus, when it's incredibly simple to achieve (just add a style for a:focus in your style sheet). Penn did this, and consequently it's very easy for sighted keyboard users to keep track of their position as they tab through the page. They also included a keyboard-accessible dropdown menu. However, there are some dynamic features on the Penn home page that really need ARIA markup for full accessibility. They also have a few contrast problems, most notably their slideshow navigation, which is red-on-red:

Screen shot from Penn home page showing red buttons and text on a red background

Other Good Examples?

These examples may or may not be the most accessible websites on the planet, but I think they're very good. Since the first criterion for inclusion on this page is use of ARIA role="main", there are certainly plenty of other accessible sites that have not yet added this feature, as well as other accessible sites that aren't among the top 10,000.

If you know of other sites that you feel are outstanding examples of accessibility, please share those in the Comments. I'm particularly interested in sites that have made challenging content accessible, e.g., using ARIA.

Accessible Dropdown Menus

A couple weeks ago at the 27th Annual CSUN International Technology and Persons with Disabilities Conference I gave a presentation on accessible dropdown menus. In that presentation, I walked through several examples of accessible menu techniques (and a few not-so-accessible ones). All the examples are available on my Dropdown Menus Test Page.

Screen shot of a dropdown menu with top-level menu items About, Academics, Admissions, and Visitors; the Academics dropdown menu is open and visible

Dropdown and flyout menus on websites are great for reducing clutter, simplifying page content, and providing a consistent navigation structure that (if done well) makes it easy to find content from anywhere on the site. Unfortunately, very few of the dynamic menus in use today are fully accessible:

  • Most dynamic menus depend on users being able to use a mouse. Mousers hover over menu items, which makes dropdown menus appear. If non-mousers tab to those same top-level menu items, they typically can't make the dropdown menus appear.
  • Most dynamic menus depend on users being able to see. Dropdown menus are typically hidden with display:none in CSS, and revealed by changing that to display:block using JavaScript (triggered, as noted above, by a hover event). If screen reader users can somehow trigger the change from hidden to visible, that change is not likely to be communicated to them, so even if the dropdown menu is visible it isn't necessarily accessible.
Continue reading

Windows High Contrast and Background Images

In 2012, I resolve to think more broadly about who visits my websites. One group of users that often gets slighted, even by designers who are otherwise accessibility-conscious, is individuals who have difficulty perceiving or processing dark text on a light background. All major desktop operating systems, and some mobile operating systems, include optional high contrast color schemes that invert colors or remove color altogether. These color schemes apply across all applications on the device, including web browsers.

One would think this wouldn't present any major problems for web designers. If a web page is created with good contrast between foreground and background, there will still be good contrast when colors are reversed.

The problem, however, is background images. When users enable high contrast mode in Windows, CSS background images are no longer displayed. This isn't a problem in Mac OS X, but as far as I know this has always been an issue in Windows. It certainly is true in Windows 7 and Vista. The implications for designers?

Don't use CSS background images to deliver content.

Continue reading

Back to Basics: Skip to Main Content Links

One of the earliest solutions in all of web accessibility was the "skip to main content" link, a same page link at the top of the page that enables users to skip past navigation links and go straight to the main content of the web page. Despite the fact that these links have been in use since the early 1990's, they actually aren't implemented well at all by browsers. They can be a huge benefit to sighted non-mousers (navigating by keyboard) but they don't work for these users in any browser other than Firefox and Internet Explorer, and they don't even work in IE unless link targets have tabindex="0". This blog post discusses all of this, and ultimately proposes a simple JQuery solution that makes same-page links work beautifully in all browsers.

Continue reading

To Beard or Not To Beard

That is the question. I actually went several years with full beard. Since then, I've tried repeatedly to grow it back but can never quite get over the hump. This post is my way of motivating myself to stick with it, at least until Christmas so I can pretend to be Santa.

Reasons To Beard

  • It's cold outside, and beards are warm.
  • Not shaving frees up 5 minutes each day, or 30 hours a year.
  • Shaving is unnatural. If it was supposed to be shaved, it wouldn't keep growing back.
  • Bearded, I will be helping my home town remain the beardiest city in America
  • Many of my intellectual, artistic, and spiritual heroes throughout history were non-shavers (see my Beard Gallery below).
  • My 11-year old daughter wants to use my giant beard for art.
  • My beard is coming in white. This enhances my credibility in academia.

Reasons Not To Beard

  • Beards are itchy (especially during this transition from Non-Bearded to Bearded. Each time I shave it's in an itch-crazed frenzy, desperate for relief).
  • Beards attract food.
  • My beard is coming in white. This makes me look old.
Continue reading