Building Web Accessibility, Part 1: Barriers, Guidelines, and Standards

“Many organizations are waking up to the fact that embracing accessibility leads to multiple benefits: reducing legal risks, strengthening brand presence, improving customer experience, and colleague productivity.” — Paul Smyth, Head of Digital Accessibility at Barclays.

Accessibility is key on the web. If you’ve read our other blog post on the topic, you’ll know what web accessibility is and why you should care. To recap, accessibility is important to the 1 billion people in the world who are disabled. And accessibility is good for business because it:

• Builds positive public relations
• Avoids discrimination and legal complications
• Contributes to a positive company image
• Boosts your SEO
• Improves usability and user satisfaction

Plus, building accessibility into enterprise-grade applications that are accessible to the disabled will increase the quality of your apps and the overall user experience (disabled or not), thereby supercharging your digital transformation efforts. Therefore, there is every reason to make web accessibility a part of all your projects.

In this blog post, we take a look at the web accessibility barriers, guidelines for accessibility compliance, and the standards for increasing web accessibility. Then in the posts that follow, we talk about ways that make it easier to build accessibility into your apps (think pre-baked templates) and everything you need to achieve top-level web accessibility compliance with low-code, HTML, CSS, and more.

What Are Web Accessibility Barriers?

Simply put, anything that restricts access to web content is an accessibility barrier. Failing to design for accessibility excludes many, denying access to services, goods, or information. Five categories of disabilities can affect access to the web: auditory, cognitive, visual, motor, and speech. Understanding «the limitations of each category helps define accessibility requirements. These requirements can be also beneficial for those who aren’t disabled. For example, if you’re holding a crying baby in one hand and you need to have a video consultation with a pediatrician on your insurance app. Or, you’re making a pie crust, have your hands in flour, and your digital doorbell rings.

As we age, we all need a little more accessibility in our life. Even the healthiest of us will see some of our capabilities decline: vision, hearing, dexterity, and so on. If you’re interested in learning more on the impact of accessibility and its various benefits, here’s a video with a series of examples.

So now you’re asking yourself, “Where do I start?” and, “Are there guidelines that will help me be compliant?” It’s time to bring out the Web Content Accessibility Guidelines (WCAG)!

WCAG Principles and Guidelines

The WCAG is a set of guidelines that developers need to follow to make their content accessible to a wider range of people with and without disabilities. They cover a wide range of aspects that should be addressed when building accessibility. They are based on four principles known as POUR:

• Perceivable: Users must receive information and user interface components in ways that they can perceive, such as providing text alternatives for graphical and other content with no text.
• Operable: User interface components and navigation must be operable. An example is making all functionality available from a keyboard.
• Understandable: The information on the user interface must be understandable. The user should be able to figure out how to use the interface easily; think ease of setting the language, a clear focus element on each page, and navigation consistency.
• Robust: Content must be robust enough so a wide variety of user agents, including assistive technology, can interpret it.

Under the POUR principles are 78 guidelines developers should follow to ensure their content is accessible. There are three test criteria compliance levels: A, AA, and AAA.

But wait, there’s more. The latest version of WCAG (2.1) includes additional requirements for mobile accessibility. WCAG is working on their own mobile accessible checklist, but in the meantime, check out this one from the Mozilla developers’ website. For the best web experience, developers must follow the established best practices, and the content should be WCAG 2.0 and 2.1 compliant.

WAI-ARIA and Extending HTML

Web Accessibility Initiative-Accessible Rich Internet Applications (WAI-ARIA) is a standard for increasing the accessibility of web pages, in particular, dynamic content and user interface components with ARIA.

ARIA attributes are markup extensions that add textual information to the HTML semantic tags of a page or app. HTML semantic tags describe elements to the developer, browser, or device, for example: <aside>, <figure>, <figcaption>, <footer>, <header>, <main>, <nav> , <section>, <h1>, <h2>, <h3>, <h4>, <h5>, and <h6>. By extending the HTML, screen readers or browsers can interpret the textual information and convey it to the user. For example, identifying a checkbox and whether it’s checked.

WAI-ARIA is an extension of HTML, and it provides a way for developers to add specific HTML attributes (such as an article, alert, or slider) to manipulate HTML tags. This allows for developers to extend markup to act like the standard semantic tags. Here, you can see how two different page structures will behave the same when interpreted by a screen reader by using ARIA role attribute extensions:

WAI-ARIA includes ARIA roles, states, and properties:

• ARIA roles don’t change; they apply to properties like the structure of a page (Progressbar, Button, Form, Region, Group, Search, Headings, Article, Document, Presentation, Toolbar).
• ARIA properties usually describe relationships with other elements and are not commonly changed.
• ARIA states are more dynamic and are typically changed in the Document Object Model (DOM) when users interact with the content (aria-invalid, aria-pressed, aria-required, aria-hidden, aria-current, aria-expanded, aria-haspopup). Screen readers interpret the changes and announce them to the users, to provide interaction with the page or application.

Combining WAI-ARIA and HTML is a powerful way to make content fully accessible on all browsers and devices.

Feeling Daunted?

Now that you know the benefits of accessibility, what you’re up against, and the guidelines and standards to follow, you’re probably feeling that this will take ages and a lot of hard work. Especially since you know you have to design web accessibility from day one. That’s with traditional coding, however. There is an easier way, and Part 2 of this series introduces you to development accelerators in OutSystems UI that can help, as well as comprehensive techniques for building your own custom accessibility-ready patterns using low-code or HTML and CSS.