Digital tools shape our daily lives — how we order food, how we get around, what news we hear, and how we work. If you believe in equal opportunity for all, as we do, you have to believe in equitable digital experiences.
Even if you’re not focused on equity, it’s certain that a portion of your audience relies on assistive tools to access your website: More than one billion people require assistive devices for daily life, and that number is expected to double by 2050. There are also economic factors to accessibility — for example, many people use their phone as their sole means of accessing the internet. Effectively communicating with your full audience requires attention to accessibility in various forms.
The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA.
As a standard practice, for all of our work for our clients, we aim to create websites that are fully conformant with WCAG 2.1 level AA, meaning that content can be published that meets this accessibility standard without any exceptions. This includes conventions for the front end implementation for screen reader compatibility, text resizing, color contrast ratios, keyboard accessibility, and corresponding controls in the CMS for entering metadata. We may also target level AAA for special-purpose sites, though the requirements of this level generally cannot be met within an organization’s brand.
Designing for accessibility
We recently relaunched our brand and website, taking steps to make sure our site meets WCAG 2.1 AA standards for accessibility, just like any site we would create for a client.
Even before site development started, our designers analyzed our new branding to ensure it passed accessibility considerations. For example, combinations of colors need to meet contrast ratios to be accessible to visually impaired and color blind users. Similarly, fonts and type sizes can make certain text difficult to read for some users. Building these considerations into our brand guidelines helps to ensure that the resulting web content meets our accessibility standards.
“Touch targets,” or the area on a webpage that corresponds to a certain action for users of touchscreen devices, have also become an accessibility consideration for designers. We ensure that any interactive elements, from links to form elements to controls, are sized properly for users reliant on touch rather than a mouse, including users who are unable to touch a point on a screen with precision.
Developing for accessibility
Using semantic HTML is important in our development process — not only does it help SEO and make pages more friendly to RSS feeds, it also helps screen readers digest pages and read them aloud to users with visual impairments. As we develop templates, we ensure that page content, whether headings, paragraphs, lists, charts, or anything else, has semantic meaning even without the benefit of styles.
There are countless visual clues that users whose experience is not currently impaired by any disabilities may take for granted. We ensure that content and the user’s place in it is properly described wherever appropriate. ARIA and role attributes give clues as to functionality of an element in case a user cannot see what it does. Focus states and labels help the user understand where they are in the context of a page. Alt attributes inform a user about an image, even if they can’t see it.
Testing for accessibility
These tactics are pursued by our developers and then verified by code reviewers and QA engineers. We simulate low-bandwidth environments and run audits using tools such as Axe and HTML5 Outliner to confirm that we are meeting our standards, though we will sometimes overrule a recommendation presented by an automated tool, as accessibility cannot be fulfilled simply by conforming to the letter of a specification.
We also test websites and products with different input methods. For example, we helped the City of New York build an eligibility screener — a multistep form through which users can learn their eligibility for various city benefits and programs. Among the many tests we conducted, we ensured that a user could fully interact with the screener using only a keyboard, as users may be unable to use a mouse or reach for a touch screen. Through these tests, we were able to ensure that the tool could be used by as many New Yorkers as possible.
Of course, we try to ensure that our developers, code reviewers, and QA engineers reflect the diversity of our users. No tests or simulations can substitute for the real experiences that people of different abilities may have using our websites and products. In this respect, we are not satisfied with where we are, and are striving to meet our diversity goals every day.
Accessibility requires vigilance and experience
Full accessibility is a goal to continuously pursue, not a box to check. Even on our own site, after the initial launch, we uncovered accessibility issues that we needed to further assess and fix. For example, we found that the chevrons on our homepage that change color as the user scrolled could overlap with certain bits of text and hurt legibility, specifically when viewed in landscape mode on tablet. In other cases, a seemingly minor element of a page, like social sharing buttons, was missing a heading to make that piece of the page understandable to a screen reader. While these issues might seem insignificant to some, they could totally break the experience of using the page for someone with visual impairment.
Ensuring accessibility is, first and foremost, the right thing to do. However, it is also increasingly an area of regulatory compliance, so it is important for organizations to form a point of view on accessibility to guide their website offerings. Pulling that together into a concise commitment statement can help guide the efforts of your web team and reinforce the importance of accessibility externally.
To see the standard we’re upholding, read our accessibility statement here.