Today, more people are accessing the world wide web, and using a wide variety of devices and assistants to do so, than ever before. This means it is crucial that your website works properly with all the different ways your user’s can interact with your website. Unfortunately, for many small- to medium-sized websites, ensuring that they meet these accessibility guidelines is often put to the backburner. This makes it difficult, or even impossible, for some of your users to interact with or understand the contents of your website. That is why now, more than ever, ensuring that websites meet web accessibility guidelines is crucial and needs to be a priority for anyone looking to gather an audience for their website.
This blog is intended as an introduction to the concepts of web accessibility and is meant to get you thinking about web accessibility as you build a website. This blog will by no means cover everything there is to discuss about web accessibility, as that is a topic one could dive deep into on the internet and spend hours researching!
Web accessibility guidelines are defined by W3C’s Accessibility Guidelines, or WCAG. These guidelines are split into three levels: Level A, Level AA, and Level AAA. As this is an introduction to web accessibility, we will be covering guidelines discussed in Level A. Level A guidelines are the most basic web accessibility guidelines that any website should be able to meet, even without intending to. The guidelines in this level are mostly good web design practice, which is why most websites should be able to meet these guidelines without even trying.
The guidelines for each level are broken into four different principles: Perceivable, Operable, Understandable, and Robust. If you would like to look through the guidelines for Level A, they can be found on W3C’s website here. As a note for this blog, most of the Level A guidelines fall into the perceivable and operable principles, as those are the most crucial components for ensuring a website will function correctly and be accessible.
The first guideline principle, perceivable, contains guidelines that ensure that the content of your website, as well as its interface, is presented in a way that allows your users to easily perceive it. The general theme that the Level A guidelines in this section follow revolves around ensuring that the structure, sequence, and general layout of your website are sensible and flowing.
The first of these guidelines, and arguably the most crucial, deals with the structure of your website. Assistant devices, such as screen readers, parse through your website’s HTML to provide the user with the necessary information. If the structure of your website’s HTML is not in a meaningful pattern relating to the way your website is laid out visually, this can make it incredibly confusing for users who rely on these assistant devices to interact with your website. For this reason, the flow and structure of your HTML must be the order in which you want information to be presented. You should NEVER compromise the structure of your HTML simply to meet the needs of a visual desire you have for your website. The sole purpose of HTML is to provide the browser with the information you want to be presented, in the proper order. You should be relying on CSS to make the necessary changes to that content to display it as you want to. A trick I like to use to ensure I meet these guidelines is to step back and pretend I am interacting with my website strictly through reading the HTML files. After all, this is what web assistants do! This allows me to find any information that might not have the correct structure or relationship that I want it to have, whereas I would miss that when visually looking at my website because that is how I am most used to interacting with a website.
The next of these guidelines discuss how your website handles non-text content, i.e., images, controls, input fields. For any non-text piece of meaningful content on your website, that is not used purely for decoration and visual formatting, that piece of content must have a text alternative. This is so users who do not interact with your website visually can still digest all of the content on your website. Luckily, almost any HTML element that represents a non-text piece of content already has attributes that help with this! The most important of these is the name and aria-label attributes. These elements provide both a name for the element and a subsequent label. It is crucial that the majority of the elements in your website that are not purely text contain both a name and aria-label attribute to provide the necessary information. The equivalent of the aria-label attribute for images is the alt attribute. This should be used on any image in your website and provide a text description of the image and the purpose it serves.
Finally, the last of the guidelines in this section cover sensory characteristics, such as the use of colors, shapes, sizes, orientation, or sound. Outside of web accessibility, this is still a crucial web design philosophy: instructions or content on your website should never rely solely on communicating information with color, shape, size, orientation, or sound. There must always be a text element along with it. An example of this would be the use of colored buttons with only symbols or shapes on them. A screen reader is going to have a tough time conveying the meaning of these buttons to someone, as there is no text or directions associated with the button. One way around this is doing what was discussed in the last section, adding the name and aria-label attributes so a screen reader can interpret the element. However, my personally preferred method of meeting this guideline is to simply include text in the button alongside the symbol or shape! Not only does this allow the screen reader to properly parse the information, but it also provides additional draw to the element visually by including the two different visual representations of the button.
The second guideline principle, operable, contains guidelines surrounding how a user interacts with your website. The general theme for the Level A guidelines in this section revolves around ensuring that the user can properly interact with your website on a basic level with a keyboard, can control automatic elements on your website, and can properly navigate around without getting trapped in a specific section of your website.
The first of the guidelines in this section, and many of the others, discuss the ability to properly navigate through and around your website simply using a keyboard. The most important of these guidelines, which also ties back into the previous principle, is the focus order of your website’s elements. Many users with assistants navigate through your website using the Tab key, which switches focus from one element to the next. By default, the order that elements gain focus is the same order in which your HTML is structured. However, you can also customize this focus order using the tabindex attribute. Keep in mind, if you are going to use this attribute to customize the focus order of your webpage, the order must still be in a meaningful and operable order! Another important note is that a user cannot get trapped by tabbing through the elements. This means that, if an element can gain focus by tabbing, it can also lose focusing by tabbing again.
Continuing this discussion, it is crucial that all the default functionality of the keyboard remains available on your website. This means that there should be no special keyboard shortcuts as the sole way of providing functionality on your website. Doing so could remove the ability to perform a basic task on a keyboard that a user might need to interact with your website. If you must implement a keyboard shortcut on your website, you must provide a way to turn off that shortcut or allow the user to remap the shortcut.
Another important guideline is the use of links in your website. It is crucial that any link on your website is understandable and the purpose of where it navigates to can be determined by the text alone or the text and a description associated with the link. Regarding links, it is also important that your website provide a bypass link for skipping large blocks of content that are repeated on several of your website’s pages. An example of this could be your navigation menu. At the beginning of your navigation menu, you should provide a hidden element that will link the user to the main content of that page and provide a description for the user identifying the purpose of this link.
Finally, the last section of guidelines in this principle discusses auto-timed elements. If your website contains an automatically moving, blinking, scrolling, or updating information, it can be difficult for a user with an assistant to interpret that information. If you are going to have content such as this on your website, it is necessary to provide the user with the ability to either pause, turn off, hide, or adjust those elements. This allows the user to modify your website as needed for them to have a successful time visiting your website. An important note on automatically blinking components: NEVER, and I repeat never, design an element that blinks repeatedly more than three times in a single second. This could trigger seizures or other harmful physical reactions from users, putting that user in danger. There is never a need for quickly flashing elements in a webpage, so just don’t do it.
The third guideline principle, understandable, ensures that the information and interface of your website are easy to understand. As mentioned at the beginning of this blog, most of the Level A guidelines fall into the first two principles, as those alone ensure that any basic website is accessible and understandable to a variety of users. However, there are still a couple noteworthy Level A guidelines in this section.
The first of these guidelines involves ensuring that the human language your website, or a specific element, can easily be determined by an assistant. This can be done using the lang HTML attribute, which contains the ISO code for the desired language. A list of these ISO codes can be found here. The most crucial area to include this is in the HTML element at the very beginning of your web page. Including this there will allow it to cascade throughout the rest of your HTML and allow assistants to determine the language. If you have a specific element that is a different language than the rest of your web page, however, then again use the lang attribute on that specific element to ensure users know that when they encounter it.
The next guideline focuses on predictable outcomes whenever a user focuses on an element or enters an input into your site. For both, when a user performs these actions, the context of the web page should not automatically change without letting the user know first that the context is about to change. Take, for example, a complex form. Say that one of the inputs in the form determines whether an entire section of the form is going to be displayed or not. If that were to happen without any warning, a user with an assistant might not realize at first, or suddenly be very confused where the rest of the fields in the form came from. It is important that, if a change like this were to happen, the user be notified before that the input they are on will determine the context of the rest of the form.
The final set of guidelines deals with assisting users when they are interacting with forms or inputs. To meet Level A guidelines for forms and inputs, you must provide the user with labels and instructions on the purpose of the form and how to use it when their input is required. Also, if your form includes automatic error validation, the error must be presented and described to the user in a way that is easily understandable for them. Going back to the use of color only, an improper example of this would be simply highlighting the input as red when an error occurs, and nothing else. This does not provide enough for impaired users or users with screen assistants. In addition to any coloring, an error must always include a message about the error, why it happened, and how to fix it.
The final principle, robust, ensures that websites are compatible with any current and future ways of accessing your website, including the use of assistive technologies. As mentioned at the beginning of this blog, and in the previous principle, most of the Level A guidelines fall under the first two principles. However, there are two Level A guidelines under robust that we can cover.
The first of these guidelines is the ability of your website to easily be parsed by assistants. This goes back to some of the topics we covered earlier, such as proper HTML structure and flow. The guideline states that, for a website to be properly parsed by assistive technologies, all elements must have complete start and end tags, they are properly nested and structured in the desired flow, all elements have a unique ID, and there are no duplicate attributes within a single element. Meeting all these requirements in this guideline ensures that your website can easily be parsed by assistants, allowing those assistants to easily present your website to the user.
The second of these guidelines, while it does not apply to the average web developer, is still important to understand. The guideline discusses that, for any interface component on your website, the name, role, properties, and values can be programmatically determined and set by the user. The reason this doesn’t apply to general web developers is that all the standard HTML element controls already meet this requirement! This requirement is meant for developers who would be developing or scripting their own interface components for a user to interact with. If you are to do this, as the guideline states, everything about that component must be easily understandable and controllable by the user.
With all these Level A guidelines covered, your website should be usable and understandable to most users on the web today! While Levels AA and AAA cover more complex guidelines and requirements for your website, any website should easily be able to meet most of the Level A standards, setting them up for success. I hope you are more likely to consider web accessibility when building your next website now that you have had a test of what web accessibility entails!