WCAG Demystified for the Angular Developer

Accessibility as described in the WCAG actually makes your site better for everyone. Just doing the right thing, leveraging HTML5, and using a good third-party toolkit will get you most of the way there.

Accessibility is often put in terms of “helping the disabled”—even the W3C’s introduction to accessibility starts with that approach: “When websites and web tools are properly designed and coded, people with disabilities can use them.” If you’re part of the 74% of the population that doesn’t have a disability, creating an “accessible” site may be a mysterious task.

The reality, however, is that accessibility pays off for, literally, all users with or without a disability.

You probably have an example of that in a drawer in your kitchen. In the 1990s, Sam and Betsy Farmer (working with the Smart Design firm), redesigned can openers so they could be used by people with arthritis (the OXO Good Grips can opener). Their design and its descendants were bought by everybody, with or without arthritis—it was just a better can opener.

Another example: The alt-text you add to your site’s image doesn’t just support screen readers (what the W3C refers to as a “user agent”). Web crawlers use alt-text as part of indexing pages: Sites with great alt-text get better SEO ratings.

Plus, of course, accessibility often has the force of law, especially for sites created by public services. In the U.S., the governing legislation is the Americans with Disabilities Act (ADA), with Section 508 of the Rehabilitation Act setting standards for U.S. federal websites. If you look at the federal government site which implements those standards … you just see a perfectly ordinary site. Accessibility not only improves the experience for everyone, it doesn’t require you to distort your site to meet its goals.

Having said that, you shouldn’t assume that achieving accessibility is something that will happen accidentally—you need to look at the WCAG requirements to make sure you’re doing the right things to get those payoffs for your users.

It’s worth pointing out that the WCAG requirements are designed to make your site better in four areas: Sites must be Perceivable, Operable, Understandable and Robust. From any perspective, those are goals anyone would want to achieve (there is a fifth category—Conformance—that describes the criteria required to claim that your site meets one of the levels of WCAG conformance: A, AA or AAA).

Since these requirements are all user interface issues, virtually all accessibility issues are the responsibility of the client-side developer building a page to be presented to the user. The good news here is that exploiting the features of HTML5 (and using good third-party tools) can achieve many of these goals for you.

Perceivable

The perceivable category of the WCAG requirements, for example, contains the requirements for ensuring that all users can access the information being presented page.

Fundamentally, this requirement means providing content in multiple ways so that readers can access it through whatever sense(s) work best for them (e.g., using captions and alt-text to provide a text-based version of any image or media on the site).

But providing content in multiple ways supports every user: 65% of the population choose to access information visually, while 35% choose to get information verbally (text and auditory). If you want to reach all your users, you should be providing multiple formats anyway. In addition, because visual users also read text (and vice versa), providing information through multiple channels reinforces the message you’re sending and reduces misunderstanding.

In addition, this category includes ensuring that screen readers can determine the relationships between the parts of your page and the sequence the page should be read in. Leveraging the various HTML heading and semantic tags (again, something you should be doing anyway) goes a long way to meeting this goal.

And we all probably support the WCAG’s Success Criterion 1.4.2 Audio Control: If audio starts playing automatically and continues for more three seconds, the user must have the ability to either stop the playback or silence the audio (the Angular Card with the kendoCardMedia directive supports this requirement, for example).

Operable

The primary requirement of the operable section is that the UI can’t require some interaction that a user cannot perform—on smartphones, this can come down to the “big fat thumb rule”: If a user can’t reliably use your smartphone app with just their thumb, then your UI probably isn’t very good.

The operable requirements also include implementing well-known shortcut keys (as, again, the Progress Kendo UI for Angular components do) to ensure that all functionality in the page is available from a keyboard. Your pages should also give users multiple ways to find and navigate to content so that they can use the method that makes sense to them.

Again, this category includes topics that (you would think) all site designers would do automatically: page titles should describe the page, link text and its context should describe the linked content, the component on the page that has the current focus should be obvious, and—another good idea—the page should not trigger seizures.

You wouldn’t think that last criterion would need to be mentioned, but here we are.

Understandable

Creating a page that’s understandable also includes criteria that you’re probably implementing anyway:

• Abbreviations, idiomatic and technical terms should be defined (the HTML dfn and abbr tags are designed to do this).
• Simply moving to a new component on the page shouldn’t trigger major changes to the page or its content—in fact, you should warn the user if a change the user is about to make will result in a major change to the page or its content.
• If your navigation system works one way on one page, it should work the same way on all of your pages (using a third-party navigation system across all of your pages—the Telerik UI for Angular navigation components, for example—will give you almost all of that, automatically).
• If you detect an error in the user’s input, you should a) flag it, and b) tell the user what the problem is.

And there’s another requirement that you wouldn’t think needed mentioning but yet …

Robust

The primary criteria in the robust category is that content can be interpreted reliably by a wide variety of user agents. For these requirements, it does help to understand the capability of the various user agents (screen readers and the like) that people use to access webpages.

The good news here is that user agents are constantly becoming more sophisticated and capable of handling a wide variety of pages. The bad news is that you can’t leave old and badly designed pages “as is”: Your pages must support these assistive technologies as they evolve.

It’s a Good Time to Start Being Accessible

If, when building your component’s templates, you take advantage of the features of HTML5, leverage the built-in functionality of third-party components, and just implement good client-side design, then you’ll go a long way to making your site accessible.

You can even do some automated testing to see how well you’re dong: There are multiple tools to determine if your site has significant accessibility issues. To quote the W3C, “Web accessibility evaluation tools can help you quickly identify potential accessibility issues. You can use them through all phases of the web design and development process. Tools can provide fully-automated checks, and help you with manual review.”

But, as the W3C also says, “Human judgement is required” to find out how accessible your site really is—“Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so.”

To determine how accessible your site is, you need to interact with your pages with a sceptical eye—but that doesn’t have to be hard either. Just testing how your pages work if you use stylesheets that reduce your pages to black and white with all the images removed will tell you a great deal. Attempting to interact with your pages using common user agents will also reveal a lot about how accessible your site is.

So, while HTML5, sensible design and third-party components can take care of multiple accessibility requirements, in the end (like all UI and client-side issues), accessibility is in the eye of the user. Take the time to be your own user and, in the end, all your users will benefit.