One of the hottest topics right now in web development and at Matchfire is accessibility and for good reason. As designers and developers, we can create the coolest most visually stunning experiences on the web, but if the information is not available or the site is not functional to some users, then we’re doing our clients and ourselves a disservice.
A wise person once said, “With great power, there must also come great responsibility,” and those words ring truer now than ever before in a world where web developers can create almost anything a designer throws at them. In creating these amazing experiences it is imperative that every user in our audience is considered — and it is our responsibility as designers and developers to ensure we are not excluding any of our users from experiencing our creations.
Our team has put together an overview of different items to check for when designing and developing for the web to help you greatly improve the accessibility of the content in your next build.
What does accessibility mean?
When we say the web needs to be accessible, it means that anyone should be able to use your product. Whether the user is visually or cognitively impaired, epileptic, or lacking motor skills, they should be able to access your site and all of its content. These may be temporary, situational, or permanent issues for the user, but all are just as relevant from the perspective of designers and developers.
Okay, so where do I start?
The Web Content Accessibility Guidelines (WCAG) is a shared standard for web content accessibility for individuals, organizations, and governments and is perhaps the most comprehensive resource for web accessibility standards. The WCAG site can be a bit daunting as it is so comprehensive. For that reason, I really like the A11Y Project and is our go-to for patterns and resources, and it has this really nice checklist.
Beyond the A11Y Project, there are loads of fantastic articles and resources being born every day. There is a consolidated list of resources included at the end of this post.
Designing for Accessibility
When designing, it is best to begin with accessibility in mind rather than considering it as an afterthought. It is usually much more difficult to go back through and adjust colors and font sizes after a design has been created, especially if a client has already fallen in love with the comps. Here are some key points to address in your design:
Contrast
When discussing contrast, color is the first thing that comes to mind, but color isn’t the only aspect that can affect contrast. In addition, the weight and size of the font play a part in calculating contrast ratios.
According to our friends at the WCAG, there is a contrast(minimum) — level AA and a contrast(enhanced) — level AAA. Those are described as the following:
Level AA — In order to meet the level AA success criteria, text smaller than 18 point, or 14 point for bold text, must have a 4.5:1 contrast ratio. All larger text must have a contrast ratio of 3:1 or greater.
Level AAA —The AAA is a bit more strict as it’s criteria requires text under 18 point, or 14 point for bold text, to exceed a contrast ratio of 7:1. All larger text must have a contrast ratio of at least 4.5:1.
What does this mean and how can I check my design or website? I am glad you asked. Basically, you want all of your text to pass level AA, and depending on your audience it should pass level AAA as well.
This video goes into more detail about checking for accessible colors:
For a quick check against background and text colors, Lea Verou has created Contrast Ratio, a web app that will quickly tell you how your color combo scores.
Then there are more robust online resources, like Cloudflare’s color contrast checker. This tool has a lot more options and is useful for viewing different elements, and provides suggestions for different color combinations within your defined palette.
For designers, there are several plugins that integrate directly into Sketch, XD, Figma, etc. Here at Matchfire, our design team uses the Stark plugin to check for color contrast. It also has a colorblind simulator and suggests contrast friendly color combos for you. This is a great tool that assists our designers in making informed color decisions.
For developers, there is a great extension called aXe, available for Chrome, Firefox, and Android, available here. This plugin is accessible within developer tools and not only helps with color contrast but a slew of other accessibility checks.
Color
Text and element contrast isn’t the only role that color plays in design. Often we use colors to dictate success or failure of an action, or relay other messages important to the user experience. But for people who are color blind or have other vision issues, these uses of color aren’t serving their purpose. It is highly recommended for these uses of colors to be complemented with additional text or iconography that will communicate the same thing as the color was intended to.
Fonts/Text
Beyond the contrast of the text and the background, here are a few other suggestions to improve the readability of your content.
- Try to avoid lighter weights where possible, as to avoid contrast issues.
- Keep font sizes at 16px and greater for body copy.
- Try to avoid centered and justified body copy — both will make the text more difficult to follow and read, especially for users with impairments.
Focus states
Anything that a user can interact with should have a focus state. Focus states are different than hover states as the user generally activates them by using their keyboard or a device other than a mouse to navigate. Adding focus states to elements provides visual clues as to what the user can interact with. As you can see here, the default focus states for interactive elements differs per browser.
We can, but do not need to stick to these defaults. As designers, you can get creative with focus states, just as you do with hover states. There are a few items to consider:
- Avoid using only a color change for a focus state, as someone that is colorblind or has low vision will have a more difficult time distinguishing.
- Try using borders or background colors for a more significant difference between default and focus states.
- Animation helps draw the user’s eye.
Focus states are an easy, yet important way we can improve the accessibility of our products. This article from deque.com has examples and further information regarding best practices for designing focus states.
You can do it
You may already be implementing these concepts into your designs, and good on you for that, but if not, please take the time to learn more about these considerations and begin to introduce them on your next project. Once you start, it will become second nature when you are designing and will undoubtedly make your product better.
Developing for Accessibility
As developers, we have a lot to worry about as it is — bugs, different viewports, differences in browser support, adapting to new technologies, etc. The list is not short. With all the complexities of our development process, it is easy to let something like accessibility fall by the wayside. But, just as we have adapted to responsive design and new javascript frameworks, it is necessary to include accessibility improvements into our workflow. The list below is in no way comprehensive but serves as an introduction to some terms and concepts that will hopefully lead to further research on your part.
Semantic HTML and Aria
Both of these concepts, semantic HTML and ARIA(Accessible Rich Internet Applications), are meant to provide more information to screen readers about where the user is at and what is happening on the page. Before HTML5 and the introduction of landmark elements like <nav>, <main>, and <footer>, ARIA helped designate these landmark sections throughout the page. These HTML5 elements have built-in ARIA roles, so it is no longer necessary to add aria roles to them(eg. Adding role=”navigation” to the <nav> element).
This video explains a bit more on what ARIA attributes are:
Currently, the main purpose of ARIA is to communicate dynamic changes in roles and states to assistive technologies. Think about modal windows, accordions, or hamburger menus — these all have interactions that have visual effects associated. Any user relying on a screen reader doesn’t have any context for when an accordion or modal is opened, and that is where we can lean on ARIA to help us.
These type of elements generally use javascript to trigger them, which we can utilize to update the aria attribute when a user interacts with them. For example, changing aria-expanded from false to true on both the hamburger menu button and the menu container when it is opened. There are many different types of these components that we use on a daily basis and associated aria attributes that may apply to each. Luckily for us there are many resources that have created and tested many of these patterns. For example, the a11y Project, has put together a great list with examples and github repos.
ARIA can still help us with static elements, for example a link with only an icon contained, or perhaps an element that you would like to hide from a screen reader. Regarding static elements, using semantic html in the right way can greatly help by making your page easier to follow by a screen reader user. There is a great article on CSS-tricks, How to Section Your HTML, which goes into great detail explaining landmark elements, how and when to use them, in addition to complimenting them with ARIA attributes.
One caveat about using ARIA is that not all screen readers, browsers, and operating systems have the same level of support. The best thing to do is test your implementations with real screen readers. EBAY’s OATMEAL project suggests:
- JAWS with IE on Windows
- NVDA with Firefox on Windows
- VoiceOver with Safari on Mac OS
Focusable elements and tabindex
Much like using ARIA attributes to tell screen readers which elements have the ability to be interacted with, we need to give these elements the ability to gain focus with a keyboard. In general, the <button>, <a>, and form elements(<input>, <textarea>, etc.) have default focus from the browser. When you need a different type of element to obtain focus, adding a tabindex is the answer. This should be a rare occasion and you should ensure that there is not a better solution to accomplish what you are after. But, if you absolutely need to do so, you can add tabindex=”0” to any element to add it to the tab flow.
That being said, adjusting the values of tabindex will have different effects. A value of “-1” will take the element out of the tab flow. This can be used when you would like to perhaps take the element in and out of the tab flow with javascript. A positive value of “1” or greater will give that element a higher priority in the tab flow. It is never recommended to apply a tabindex greater than 0, EVER, as noted here, here, and here.
The important thing to remember is that if there is some sort of interaction that occurs by using a mouse, it should be able to be achieved using the keyboard, and that begins with the focusing of the element.
Accessible Images
Users who are navigating your product with a screen reader will more than likely not be able to see any of the images used on your site or app. To best accommodate these users, we need to include appropriate alt=”” text to accompany these images. Alt text can be beneficial for SEO or for sighted users when images don’t load, but are imperative for assistive technology users. The text used should describe the image in detail. Shopify has a great article, which describes best practices when writing alt text. It is important to ensure that each of your images have not only an alt tag, but sufficiently descriptive alt text. In the case of images that are purely decorative and adds no additional context to the page, it is recommended to still include the alt attribute on the <img> element, but leave it blank(alt=“”).
When using inline svgs, we can use the <title> and <desc> tags to add a title and description of the svg. More information can be found in the, Accessible SVGs article on CSS-tricks.
Animation
Users with a vestibular disorder can become dizzy by moving or the environment around them moving. Anyone can suffer from this and it can be temporary or permanent, caused by illness, injury, or a genetic condition. This condition affects the inner ear and in turn balance — whatever you are looking at appears to be moving, even if it is not. This makes viewing animations or other moving elements on your site very difficult to handle for these users.
So, what can we do? Do not autoplay videos, carousels, or animations, and give the user the option to start and stop the motion. We can also use the prefers-reduced-motion media query in our css to provide an alternative to animations or moving elements. Currently, this is only available in Safari 10.1 and greater, but other browsers will hopefully utilize the media query soon. More information on prefers-reduced-motion can be found here.
Wrapping up
This overview is just the tip of the iceberg when it comes to accessibility on the web. There are many great articles and resources that go into much greater depth on each of these topics. Whether you are a designer, developer, or project manager, we all need to put in the effort to make our products more accessible to everyone. Accessibility is about inclusivity and it is our responsibility to remove barriers and open the doors of our products to all of its users.
Resources:
https://a11yproject.com/
https://www.w3.org/WAI/standards-guidelines/wcag/
https://dequeuniversity.com/
https://webaim.org/
https://developer.mozilla.org/en-US/docs/Web/Accessibility
https://axesslab.com/
https://ebay.gitbook.io/oatmeal/
https://www.digitala11y.com/
http://adrianroselli.com/