The 2021 WebAIM Million Report is now available. This annual accessibility analysis of the home pages of the top one million web sites provides insight into the current state of and trends for web accessibility. The report provides details into technical aspects of accessibility and comparisons for many types of home page categories, such as by TLD, document language, site sector, and technologies in use. The WAVE web accessibility testing tool was used to analyze the 1,000,000 home pages.
Here are some interesting and noteworthy items from this year's analysis:
- The number of detectable accessibility errors was 51.4 on average per home page. This was an improvement from 60.9 errors just one year ago.
- The number of elements on the average home page was 887, a slight increase from 864 in 2020. At 51.4 errors per page, users with disabilities would expect to encounter detectable errors on 1 in every 17 home page elements.
- 97.4% of home pages had detectable WCAG 2 failures. This was a small improvement from 98.1% in 2020.
- Home pages most commonly had low contrast text, missing alternative text, missing form input labels, empty links, missing document language, and empty buttons.
- 86.4% of home pages had low contrast text averaging 31 instances per home page.
- 26% of images had missing alternative text. Over one third of all images analyzed had detectable accessibility issues.
- Nearly half of all form inputs were not properly labeled.
- The proper use of headings in home pages is increasing over time.
- ARIA usage increased 25% since 2020 with 68% of home pages utilizing ARIA and an average of 48 ARIA attributes per page. Home pages with ARIA present averaged 41% more detectable errors (24 additional potential barriers per page) than those without ARIA. An increase in ARIA attributes aligned with an increase in detectable web accessibility errors.
- 79% of home pages had a valid HTML5 doctype. HTML5 pages had nearly double the page elements and 35% more accessibility errors than pages with other doctypes.
- Web site categories that were subject to increased civil rights complaints and lawsuits in 2020 were among the most improved.
- There were significant differences in detectable accessibility errors based on top-level domain. For example, .ru (Russia) and .cn (China) home pages had around double the errors as .us (United States) and .ca (Canada) home pages.
A password field is a text input with a type of 'password'. Browsers understand this and make the input behave in a specific way, for example, by obscuring the characters and preventing the contents from being copied.
Since this behaviour is handled by the browser, the only way to make a password visible is to change the input type from 'password' to 'text'. An alternative could be to duplicate the password outside of the input, where it would not be obscured, but this would require an additional level of complexity and might cause confusion to users.
[...] Browsers make sure autocomplete doesn't happen for password inputs, as it could allow someone else using the same device to use your password. Instead, password managers allow users to store and manage their passwords as they choose.
If we showed the password by changing the password input into a text input, then the browser might remember its contents with autocomplete. We could have added an attribute to the input to set autocomplete to off, but this is not widely supported across different browsers and can have unpredictable results.
[...] Screen reader users might not be able to see the password once it's shown, but they can still have it read to them. They also need to know something has happened when they press that button, and the current state of their password visibility.
Initially when the button was pressed we used the aria-live attribute on the password input to announce the password. This seemed like a good idea until we considered the security implications of a user doing this accidentally. Showing your password in a public space could allow someone in sight of the screen to read it, but making the screen reader announce your password could allow anyone within earshot to hear it.
To reduce this risk we added some hidden text and applied the aria-live attribute to that instead, so when screen reader users press the button they are told "your password is shown" or "your password is hidden". They can then choose to focus on the password input if it is safe to do so.
This was a great "Today I Learned" for me from Josh W. Comeau. If the
<input>is 16px or larger, Safari on iOS will focus into the input normally. But as soon as the
font-sizeis 15px or less, the viewport will zoom into that input. Presumably, because it considers that type too small and wants you to see what you are doing. So it zooms in to help you. Accessibility. If you don't want that, make the font big enough.
In addition to making sure your alt description is accurate, there's one other thing you can do that makes for a good experience: ending your alt text string with punctuation.<imgsrc="puppy.jpg"alt="A golden retriever puppy wearing a tiny raincoat."/>
The presence of end punctuation such as a period will make the voice pause a bit before announcing the next words in sequence for most assistive technology that utilizes a synthesized voice. This makes the transition to non-image content feel a lot more natural.
While alt text end punctuation isn't technically required for compliance, it makes for a better experience for your audience. These little details demonstrate care and consideration, and are noticed and appreciated by those who rely on them.