All of this really highlighted the value of accessibility-minded development and pre-launch testing—in a wide variety of browser-screen reader combinations—to ensure that all website visitors enjoy a consistent, equivalent experience.
The Web Content Accessibility Guidelines (WCAG) 2.0 are the most popular standard for web accessibility, and have been cited by the U.S. Department of Justice as an acceptable metric for compliance with the Americans with Disabilities Act. WCAG 2.0 contains several guidelines to help people with four different classes of disabilities: vision, hearing, motor, and cognitive.
People on the autism spectrum have a wide range of conditions, and many of them can face difficulties with cognition when using the internet. Some of the most relevant WCAG 2.0 recommendations for people with autism are:
- Navigation and layout should be consistent across the entire site. Performing the same or similar actions on similar user interface elements should produce similar results.
- The site should still be usable at larger text sizes and should still function with images and styles disabled. However, images, icons, and graphics that help with comprehension can be included.
- Clutter and distractions should be minimized. Style and white space should separate content and direct the user’s attention as appropriate.
- The text should be as simple as possible, while providing definitions for any non-standard terms, such as idioms, jargon, and abbreviations and acronyms. Correct grammar and spelling are important.
- Users should have as much control as possible over the site’s behavior. Avoid time limits on content or automatic refreshes whenever possible. Provide clear instructions and error messages when filling out forms.
When is a heading not a heading? Serious question, the answer lies behind one of the most common accessibility problems on the web.Dos buenos ejemplos:
Headings are much more than a big bold title, they provide a solid structure to the webpage. Think of headings as an outline of your webpage.
The structure should be portrayed both in a visual and technical manner, so people can see the structure, and screen readers are able to identity the structure in order to read it out.
Users who can see the page decide within seconds whether or not the content is relevant to them by skimming through headings, glancing over sub-headings keeping an eye out for significant keywords. Breaking up content with headings allows the page to be easily scanned by the user
Without a heading structure, you force users to do extra work to find the information they’re looking for, who has the time and luxury?
From an accessibility point of view the structure in the code should align with the visual presentation and make sense as a “table of contents” for the page.
Use headings to introduce content, they are labels not statements.
If the live stream doesn't show automatic captions, it could be due to one or more of the following reasons:
- The feature hasn’t been enabled for the channel, as we are slowly rolling out to channels with more than 10k subscribers.
- Channel is streaming in ultra low or low latency (such as a mobile live stream). Live automatic captions are only available for normal latency streaming.
- The language in the video is not yet supported by automatic captions.
- The video has poor sound quality or contains speech that YouTube doesn't recognize.
- There are multiple speakers whose speech overlaps or multiple languages at the same time.
Accessibility is one of those things we all wish we were better at. It can lead to a bunch of questions like: how do we make our site better? How do we test what we have done? Should we spend time each day going through our site to check everything by hand? Or just hope that everyone on our team has remembered to check their changes are accessible?
This is where automated accessibility tests can come in. We can set up automated tests and have them run whenever someone makes a pull request, and even alongside end-to-end tests, too.
Automated tests can’t cover everything however; only 20 to 50% of accessibility issues can be detected automatically. For example, we can’t yet automate the comparison of an alt attribute with an image’s content, and there are some screen reader tests that need to be carried out by hand too. To ensure our site is as accessible as possible, we will still need to carry out manual tests, and I will cover these later.
