By Riley Major, 2018-04-26.
Accessible360 helps organizations make their products and services accessible to more people. Automated tools only catch a small set of usability issues and often mistakenly highlight non-issues (“false positives”). Having real people use your site with real-world accessibility devices (e.g. screen readers) is the best way to discover the real barriers to access. Accessible360 can help with that (much like AccessWorks, mentioned by Nic Steenhout at MidwestPHP).
But checking a site after its built is an expensive way to ensure accessibility. It’s usually much harder to fix issues at the end of the development cycle than to bake them in from the start. Accessible360 will partner with you during your design process to forestall costly mistakes.
Being welcome to users with different abilities isn’t just the right thing to do; failing them can get you into legal hot water. Although the ADA wasn’t written with websites in mind, it is being applied to the digital realm.
— Riley Major (@RileyMajor) April 26, 2018
Users with vision impairment often use screen readers to access web content. The best way to understand is to experience it yourself using a free option such as NVDA. But it helps to remember that there is no “layout” from the reader’s perspective; there is no concept of something being next to, above, or below something else. There is no “proximity” is visual space. It’s one long line of text, and it’s usually presented in the order of the DOM, not in the order it appears on the screen.
As a former high school debater and someone who listens to most podcasts and YouTube videos on double speed, I thought I could understand speech at a pretty good clip. But that’s nothing compared to the blazing pace traditionally used by users of screen readers. You have to speed things up because of the deluge of mostly irrelevant information. Sight has the advantage of being able to survey a whole scene rapidly and focus on a key area; a screen reader often has to slog through everything linearly. You can provide similar capabilities to screen reader users by using semantic markup. That allows keyboard actions to skip large sections. For example, hitting “h” will jump from heading to heading, as determined by HTML heading tags. That’s only helpful if they’re used to convey relative importance of headers and not (merely) to change the size of text.
The official, comprehensive recommendations from W3C are the Web Content Accessibility Guidelines. But a good part of making a website accessible is by staying pure to the core concepts of the modern web– separating style from content, and ensuring content is wrapped with semantically relevant markup.
HTML5 introduced organizational tags such as header, nav, main, article, and footer; use them. And there are all sorts of new input types for forms (such as “tel”, “email”, and “number”) which come with free UI improvements in modern browsers which are more likely to be accessible than third party libraries. Ensure that labels describing form fields are encased in label elements which reference the correct input element; remember the label doesn’t “look” like it’s next to the input box to a screen reader.
And don’t use tables for layout– screen readers read them as if they were full of data. An exception can be made for HTML emails, because of the terrible state of CSS support and consistency across email clients, but consider using the ARIA Presentation label. (ARIA (Accessible Rich Internet Applications) properties are extended attributes of standard HTML tags which provide more information about your content to accessibility tools like screen readers. Be careful with them, as used wrongly, they can cause your website to be less accessible.)
Pop goes the page
Be careful with modal windows. Often, they are added at the end of the DOM, so while they appear immediately and obviously on screen, they aren’t read until the end of the entire page, unless you set focus on one of their elements. Users should be able to close the box with the escape key, and your close button should be labeled “close”, not “x” which matches the visual of a standard close icon but reads like a letter. Also remember that screen reader users won’t know they’ve tabbed out of a dialog box– there is no visual box in that environment– so don’t let them accidentally do it.
Single Page Applications also bring some unique challenges to accessibility because of how often the DOM is changed. On screen, the change is immediately visible (our visual perception is attuned to that motion), but a screen reader might not read the new information without specific prompting (such as a change in focus, page titles, or URLs).
Chrome has built-in accessibility audit in the developer tools, but automated checks only catch about 30% of issues. The best way to learn of issues to experience them directly using a screen reader or by getting feedback from users with disabilities.
1 in 5 Americans– 56.7 million people– have a disability. Welcome them by making your site accessible with semantic markup and conventional behavior. And consider enlisting help from professional accessibility advisers and testers to help guide you.