By Riley Major, 2018-04-26.

I attended the JavaScriptMN Meetup last night (video). Due perhaps to the larger attendance, it was on the 9th floor of the Olson building rather than the more common 6th floor meeting space. After plugs for sponsors Twilio, TrackJS, and FrontEnd Masters, Kelly Heikkila and Aaron Cannon from Accessible360 gave the main presentation on A Pragmatic Developer’s Approach to Digital Accessibility.

Background

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.

Think about accessibility at the beginning of a project. Spend your money on developers, not lawyers. @Accessible_360 at @JavaScriptMN pic.twitter.com/4hlaruFlPW

— Riley Major (@RileyMajor) April 26, 2018

Screen Readers

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.

Standards

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 stick to conventions. “span” elements should not be actionable; they help control decoration. Use buttons and links for click actions. Don’t use JavaScript to control the behavior of a bunch of disassociated checkboxes; use radio buttons.

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).

Testing

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.

Closing

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.

Thanks, JavaScriptMN, for using your platform to highlight these issues and thanks also to Kelly Heikkila and Aaron Cannon of Accessible360 for sharing your experience and tips for us to make better accessbility choices.