Category: webaim

About the HTML Epidemic, WebAIM “Million” Report, and Teach Access

It’s been about a dozen years since I first realized that there is a world-wide HTML epidemic. Although I speak about the importance of semantic markup and tweet about it often, I wish I’d written specifically about it before. Thankfully others have such as Bruce Lawson, Manuel Matuzovic, and Laura Kalbag.

Web developers overwhelmingly fail when it comes to implementing semantic HTML, whether they actually know how to or not. There are many negative ramifications of this in the areas of device interoperability, reader modes, converting to PDF and EPUB formats, SEO, graceful degradation, code consistency/maintenance, and demonstrating professionalism. But particularly web accessibility.

WebAIM Million

Recently, WebAIM published a report analyzing the accessibility of the top one million website homepages in the world, called The WebAIM Million. This is striking empirical data on how poor accessibility is and how poor the quality of HTML is on the Web. For example, here are some figures from the study.

  • There was an average of 59.6 [accessibility] errors per page.
  • 97.8% of home pages had detectable WCAG 2 failures.
  • 5 of the top 6 issues were due to solely to improper HTML (missing alternative text for images, empty links, missing form input labels, missing document language, empty buttons).
  • 2,099,665 layout tables were detected compared to only 113,737 data tables (note that tables are for data, not layout).
  • On average, home pages had 36 distinct instances of text with insufficient contrast.

This is obviously bad. And, it’s important to point out that the study was done using an automated tool, which is capable of detecting only a portion of actual accessibility issues/errors. I estimate that the amount of issues would at least double or even triple if full audits were done.

Also, as a result of web developers’ poor HTML implementation, accessibility consultants are increasingly required to teach HTML to web developers rather than address “actual” accessibility issues.

illustration of the letters HTML written on a chalkboard with confused cartoon-like character pointing to it

Resolving the HTML Epidemic

This is obviously a huge problem that must be addressed. What can we do to help resolve this HTML epidemic?

Digital accessibility must be considered when hiring and training employees. Accessibility must be considered when creating a web-based product. Accessibility must be a part of ongoing training for web professionals. Accessibility needs to be taught in education.

An organization called Teach Access (@teachaccess) is helping in some of these areas. Teach Access is a group of tech companies (including Apple, Google, LinkedIn, Adobe, and Microsoft) which is preparing designers, engineers and researchers to think and build inclusively. They have several initiatives including Faculty Grants and a web accessibility tutorial. And another way to fight the good fight for HTML semantics and accessibility is to become a member of Teach Access.

Teach Access is in partnership with PEAT (Partnership on Employment and Accessible Technology) which is a program funded by the Office of Disability Employment Policy, U.S. Department of Labor.

Teach Access logo

If you’re involved in education, please reach out to teachers and professors about Teach Access and about digital accessibility in general. HTML and web design are often part of computer science, software engineering, and mass media, advertising, and news programs. You can also offer to give a guest lecture.

If you have further ideas on how to improve the use of HTML semantics (and web accessibility), please leave in a comment on this post.

Directly Related Articles

More Related Articles

Related Tweets

Assistive Technology Surveys

Digital accessibility experts are often asked about the usage of screen readers and assistive technologies. For example, one will often ask “What’s the most popular screen reader?” This is difficult (if not impossible) to determine technically, but also has privacy implications and other problems.

The following two surveys provide great data and are provided by very reputable organizations. Keep in mind though that the respondents were not controlled and the sample sizes are relatively low.

Are you aware of any other recent surveys?

Related:

A person using a laptop computer wearing headphones and touching a braille output device.
A person using assistive technology.

About Carousels and ARIA Tabs

Jared Smith (@jared_w_smith) of WebAIM recently launched a clever web page on why carousels are not good practice called Should I Use A Carousel? (which totally went viral on its launch day!) There is a slide deck Keyboard and Interaction Accessibility Techniques (on Slideshare) for which this website was made. I was fortunate enough to see Jared present this at Open Web Camp 5 July 13 at PayPal.

Jared presenting at OWC5

I don’t think that a carousel itself is super terrible. But in my experience, carousels are hardly ever coded with accessibility in mind and hardly ever designed with decent usability. In addition, supporting smaller devices is an issue and coupled with the poor usability data, carousels are overall a bad idea. If you absolutely must implement a carousel, here are some design/interaction tips:

  • Let the user start the carousel animation.
  • Give the user the ability to pause the carousel.
  • Ensure the controls have textual labels.
  • Ensure the control of the currently displayed panel is indicated visually and programmatically.
  • Ensure the controls have ample hit areas (for mobile, fine motor disability).

On the development side, a carousel can be challenging to make screen reader accessible. It seems that the most straight forward approach is to use the ARIA tab model which is pretty straight forward and fun to do! Here’s a summary of what to do in the markup:

  • Each carousel content container has a role of tabpanel.
  • Each control, typical designed as dots, has a role of tab.
  • The container of the controls/tabs has a role of  tablist.
  • Add aria-labelledby to the tabpanels which point to the id of the associated control/tab.
  • To each control/tab, add aria-controls (which points to the id of the associated tabpanel) and aria-selected (boolean) attributes.

Here are some code resources to help make sense of this. This first by Marco may be most relevant:

More:

Updated August 2017

About WebAIM Screen Reader Survey 4

As you may have heard, the results of the fourth WebAIM screen reader survey are now available. The survey provides valuable information on about screen reader users such as primary screen readers used, browsers used, and reasons for use.

WebAIM reports that problematic items have changed little over the last 2 years. The top ten are:

  1. The presence of inaccessible Flash content.
  2. CAPTCHA – images presenting text used to verify that you are a human user.
  3. Links or buttons that do not make sense.
  4. Images with missing or improper descriptions (alt text).
  5. Screens or parts of screens that change unexpectedly.
  6. Complex or difficult forms.
  7. Lack of keyboard accessibility.
  8. Missing or improper headings.
  9. Too many links or navigation items.
  10. Complex data tables.

Conclusions from the survey include:

  • JAWS is still the primary screen reader, but usage continues to decrease as usage of NVDA and VoiceOver increases.
  • The perception of accessibility of web content is decreasing.
  • 72% of the respondents use a screen reader on a mobile device, up from only 12% three years ago.
  • iOS device usage is significantly increasing and well above that of the standard population. Screen reader users represent a notable portion of the iOS device user market. Usage of Android devices is well below that of non-disabled users.
  • The use of properly structured headings remains of great importance. 

Here are a few great analyses of the survey:

WCAG Improvements

It was such a relief when WCAG 2.0 became a W3C Recommendation back in December of 2008. But in the fast paced world of the web, nothing stays the same for very long. Even WCAG could use many improvements, especially after over three years. (Time sure flies!)

Jared Smith (@Jared_W_Smith) of WebAIM recently wrote an excellent article WCAG Next which explains some of the top issues and suggests how they can be improved. I pretty much agree with all. Here is a summary:

  • Remove the CAPTCHA Exception – should prohibit all CAPTCHA at Level AA.
  • Media Guidelines – a few suggestions here plus a recommendation for restructuring.
  • Contrast at Level A -minimal contrast requirement needed for Level A.
  • Decrease the 200% Text Resizing Requirement -biggest burden of Level AA.
  • Clarify Images of Text -this is subjective.
  • Specify Mechanisms to Bypass Blocks – add techniques such as skip-to, headings, landmark roles, and others.
  • “Can Be Programmatically Determined” -a confusing aspect of page conformance.
  • Require Keyboard Focus Indicators at Level A – “There is no reason why this should not be a Level A requirement.” Totally!
  • Remove Parsing Requirement – no direct benefit and difficult to test for accessibility; possibly move code validation requirement to Level AAA.