Web Accessibility at Vida
What Is Accessibility and why is it important?
What is accessibility? Broadly speaking, when a site or application is considered accessible, it means that the site’s content is available and its functionality can be operated by anyone in their normal modality. Meaning, a site or application’s content and features are accessible regardless of the mode of access, be it a keyboard, mouse, touchscreen, choice of browser, screen reader, or other technologies.
To put it another way, quoting Google in their Fundamentals Of Accessibility Series:
Accessibility, then, refers to the experience of users who might be outside the narrow range of the "typical" user, who might access or interact with things differently than you expect. Specifically, it concerns users who are experiencing some type of impairment or disability — and bear in mind that that experience might be non-physical or temporary.
With that said, although we tend to center our discussion of accessibility on users with physical impairments, we can all relate to the experience of using an interface that is not accessible to us for other reasons. For example, have you ever been on your favorite website and accessed it from let’s say, your phone or mobile device and been unable to find a familiar menu, perform a familiar action, or access content and its missing or in a different, non-standard place? Ever visited a site on a mobile device or tablet and it’s hard or even impossible to read or interact with? Ever seen the message "best viewed on Internet Explorer"? These are also examples of accessibility issues.
It’s important to think of accessibility beyond that of just someone with a physical impairment, and what you will find is that often, something that's a complete blocker for a few users is also a pain point for many others, so by fixing the accessibility issue you improve the experience for everyone.
Make your content POUR
In making content accessible, it's important to keep some principles in mind. In fact, WCAG standards are organized into four principles called POUR:
Perceivable: Can users perceive the content? This helps us keep in mind that just because something is perceivable with one sense, such as sight, that doesn't mean that all users can perceive it.
Operable: Can users use UI components and navigate the content? For example, something that requires a hover interaction cannot be operated by someone who can't use a mouse or touch screen.
Understandable: Can users understand the content? Can users understand the interface and is it consistent enough to avoid confusion?
Robust: Can the content be consumed by a wide variety of user agents (browsers)? Does it work with assistive technology?
It's important to keep this in mind when working on an application or site, and While WCAG provides a comprehensive overview of what it means for content to be accessible, the specifics of how to achieve this can be quite overwhelming when reading the official specification guide. To that end, an important piece of reference to have is the WebAIM WCAG 2 Checklist when authoring content or functionality for a site or application. Following this checklist, you can chart a direction for accessibility and be confident that, as long as your project meets the outlined criteria, your users should have a positive experience accessing your site or application. Keep it handy! While this guide will provide additional distilled guidelines, it's handy to have a reference to other less common cases.
A list of Do’s and Don’ts
The following is a list of do’s and don’t things when it comes to web accessibility. This is a quick top-level reference for keeping things accessible. We compiled this list from a list of references which we have cited below if you want to read more.
Do use CSS over JavaScript whenever possible. Seriously. This not only avoids many accessibility issues with being heavily reliant on JavaScript, it will also improve things like first time to interactive, page load speed, responsiveness and other important metrics for an application. This isn’t to say you shouldn’t use JavaScript (of course not!), it is to say though, that unless the complexity matches the problem CSS is usually a better way to go, and not just for accessibility.
Do use the <picture> element to serve images responsively (and responsibly!). This includes the ability to serve supported media types (such as webp with fallbacks) and serve images that scale with the correct media queries, and for assistive technology users, you can provide an <img> fallback with an alt attribute
Do prefer <strong> and <em> over <b> and <i>
Do use description lists over regular lists when creating a list that is a group of terms or descriptors. Common use cases include metadata (a list of key value pairs) or a glossary.
Do used the <figure> and <figcaption> elements to display infographics, such as svgs, charts, etc. This leverages provides a caption to all users to help under the semantic meaning of the content, as well as descriptive text via the <figcaption> for assistive technology users
Do ensure Decorative Icons that are only being used for visual or branding reinforcement have the attribute aria-hidden=”true”
Do ensure that icons that convey a semantic meaning have an alt attribute (if using an <img> ) or a title attribute
Do ensure that viewport zoom is not disable. This is often done in a <meta> tag and is handled incorrectly. Ensure instead that you have this meta tag on the page instead: <meta name="viewport" content="width=device width, initial-scale=1.0">
Do ensure that all <img> tags have an alt attribute. Alt text give a description of an image for people who may not be able to view them. When an alt attribute isn't present on an image, a screen reader may announce the image's filename and path instead. This fails to communicate the image’s content.
Do ensure that the alt text content includes the image text. For example, an image of the FedEx logo should have an alt value of “FedEx”
Do ensure that <img> tags with decratorive content have an empty alt tag (alt=””). This prevents screen readers and other assistive technology from reading out the path and filename information, and communicates that the <img> is not relevant to understanding the meaning of the content.
Do add the title attribute to <a> tags to make them more descriptive when appropriate
Do NOT use anchor (<a>) tags as buttons. This is not only bad for accessibility, because your anchor tag will not be presented correctly to any assistive technology, it leads to be practices in code hygiene (like using unnecessary javascript to handle clicks), does not leverage any of the built-in accessibility that the <button> element gets for free, and generally makes your markup more confusing and harder to maintain. Unless your are navigating to another hyperlink resource (href), a button element is more suitable to this purpose.
Do NOT use an anchor tag with an empty href, an href with the a value of just # or javascript:void , or no href at all. This is bad for the same reasons above, and those use cases can be handled by a <button>, no exceptions.
Do use the <label> element for form controls. Use a for/id pairing to guarantee the highest level of browser/assistive technology support. The only exception is <button> elements. They do not not need a <label> element associated with them.
Do use <button> over <input type=”button”> . It is more accessible and achieves all the same functionality.
Do use <fieldset> and <legend> to group form controls where appropriate. Easy question to ask yourself if you need this: Does your form contain multiple sections of related inputs? Use fieldset to group them, and legend to provide a label for what this section is for.
Do make sure that form input errors are displayed in a list above the form after submission. This provides a way for assistive technology users to quickly have a high-level understanding of what issues are present in the form. This is especially important for larger forms with many inputs. Make sure that each reported error also has a link to the corresponding field with invalid input.
Do associate <input> error messages with the <input> it corresponds to. Using techniques such as aria-describedby allow people who use assistive technology to more easily understand the different between the input and the error message associated with it. Also, it makes it easier to easily identify what has errored on a form for all users. Win-win.
Do use the button element for buttons. Buttons are used to submit data or perform an on-screen action which does not shift keyboard focus. You can add type="button" to a button element to prevent the browser from attempting to submit form information when activated.
Do ensure that controls have a :focus state. Visible focus styles help people determine which interactive element has keyboard focus. This lets them know that they can perform actions like activating a button or navigating to a link's destination.
Do use the <a> element for links. Links should always have a href attribute, even when used in Single Page Applications (SPAs). Without a href attribute, the link will not be properly exposed to assistive technology. An example of this would be a link that uses an onclick event, in place of a hrefattribute.
Do NOT use more than one <h1> per page or view. The <h1> element should be used to communicate the high-level purpose of a page or view. Do not use it for a heading that does not change between pages or views.
Do use the heading elements to introduce content.
Do NOT introduce heading elements outside of a logical sequence. The order of heading elements should descend, based on the “depth” of the content. For example, a h4 element should not appear on a page before the first h3 element declaration. A tool such as headingsMap can help you evaluate this.
Do NOT skip heading levels. For example, don't jump from a h2 to a h4, skipping a h3 element. If heading levels are being skipped for a specific visual treatment, use CSS classes instead.
DO use list elements for list content. This may include sections of related content, items visually displayed in a grid like layout, or sibling <a> elements, for example.
Do NOT use other elements in a place of a list. For instance, do not use nested <div> elements in place of a list. Lists are perfect for joining adjacent content, ordering items on a page etc. Use them!
Do ensure there is sufficient space between interactive elements on a page. Some people who experience motor control issues such as hand tremors may have a very difficult time scrolling past interactive items which feature zero spacing. This is particularly true on mobile.
Do remove horizontal scrolling. Requiring someone to scroll horizontally can be difficult for some, irritating for all. Just don’t. Please and thank you. And remember, yes I mean at all screen sizes
Do ensure that button and link icons can be activated with ease. This is particularly true of mobile, but holds for all screen sizes.
Do use a <table> element to describe tabular data. Do you need to display data in rows and columns? The table element is your friend. Don’t abuse a list for this task, it's just not cool!
Do use a <caption> element to provide a title for the table
Do use the th element for table headers, with appropriate scope attributes. Depending on how complex your table is, you may also consider using scope="col" for column headers, and scope="row" for row headers. Many different kinds of assistive technology still use the scope attribute to help them understand and describe the structure of a table.
Do identify links that open a new tab or window. For people using assistive technologies, this can be particularly disruptive. To all users, doing this will help people understand what will happen before activating the link. It is an often-cited area of frustration for many different kinds of assistive technology users and non assistive technology users alike.
Do provide a skip link to the pages main view or content.
Do remove session timeouts. If you cannot, let the person using your site know the timeout exists ahead of time, and provide significant notice before the timer runs out. It's just the right thing to do here.
Do NOT use the autofocus attribute. Note: while there are exceptions to this, unless you can already name them, you shouldn’t have used autofocus.
Do ensure linear content flow. Remove tabindex attribute values that aren't either 0 or -1. Elements that are inherently focusable, such as links or button elements, do not require a tabindex. Elements that are not inherently focusable should not have a tabindex applied to them outside of very specific use cases.
Do use landmark elements to highlight important parts of a page / view. These are elements such as <main>, <nav>, <footer> , <header>. Full list of landmark elements
Do use the correct lang attribute for the <html> element. Not only is this good for how the browser can render certain glyphs, This helps assistive technology such as screen readers to pronounce content correctly.
Do make sure that <button> , <a>, and <label> element content is unique and descriptive. Terms like ‘click here’ and ‘read more’ do not provide any context. Some people navigate using a list of all buttons or links on a page or view. When using this mode, the terms indicate what will happen if navigated to or activated.
Summary
Hope this provides a good overview of how we approach accessibility at Vida as we continue to ensure our products are accessible to everyone.
References: