An Overview of Web Content Accessibility Guidelines (WCAG) and Quick Tips.
What Are the WCAG Guidelines?
There are over 70 million adults within the United States who live with a disability who might struggle to use a website that was not designed with accessibility in mind. Making a website accessible is so critical that the United States government requires all electronic governmental websites to be accessible. The website accessibility laws are all based on the Web Content Accessibility Guidelines (WCAG), which serve as the gold standard for accessibility within websites. There are four categories within WCAG, each with its own guidelines and subcategories. These four categories are perceivable, operable, understandable and robust. The rest of this post will walk through one requirement in each subcategory of the WCAG guidelines and one way to satisfy the requirement. It is not an all-inclusive list of every requirement.
Perceivable
To satisfy the category of perceivable, there are four categories that must be met. The first category is that all non-text content, such as photos, videos, and audio, have an alternative way of viewing it. This could take form in several different ways, but the most common way that this appears is through images. One of the key items when designing accessibility is putting alternative text on photos. There are modern tools out there that are helpful for designing alternative text for websites. One such tool is Microsoft Copilot. For example, the following photo of Worldwide Technology's (WWT) headquarters is going on a website.
Generating alternative text for this image using Copilot can be done without using substantial amounts of prompt engineering. Simply upload it into Copilot with the prompt "write alternative text for this photo". With this image, the following text was displayed, "A modern, multi-story office building with large glass windows, labeled 'World Wide Technology' at the top in white text next to a red and black logo. The building is illuminated from within and reflected in a calm body of water in front of it. The sky is clear with a gradient from blue to light at the horizon, indicating either dawn or dusk. Trees with autumn foliage are visible on the right side of the image". It is important to note that when using AI tools such as Copilot, it is important to always double-check the alternative text for accuracy. In this example, much of what the AI got was correct; however, there was a minor error in the description of the logo. It claims the logo is red and black, but the logo is red and blue. Another change needed for this is to specify the indication of dawn or dusk. Another issue with this generated logo is that it is long. Alternative text for most images should be between 2-3 complete sentences. This can be fixed using the same copilot tool, this time with the prompt, "Write a WCAG compliant alternative text for this photo to be put on a website. It should be no longer than 2 sentences". The output for this is "A modern office building with large glass windows displays the 'World Wide Technology' logo at the top. The building is lit from within and reflected in a calm body of water at dusk, with autumn trees on the right". As with all AI-generated text, a review for accuracy is needed. This second text has no accuracy errors; thus, it is acceptable to put in the <img> tag with the modifier, <img src = "image" alt = "alternative text"> in the html code for the website.
The next subcategory of WCAG is time-based media. This can take place in several ways. One such way that time-based media occurs is through video or audio. This type of media is a wonderful way to express ideas and thoughts; however, it is not always accessible. An effortless way to make an audio file more accessible is by inserting a choice to view a transcript. Creating a transcript is easy and can be done directly in Microsoft Word. Once the audio file is gathered, and Word is open click on Home -> Dictate -> Transcribe,
Once Transcribe has been selected, select the language of the audio file, then hit Upload Audio.
.
Once word has finished transcribing the audio file click on add to document and select Just Text if it is a short audio file with a single speaker, With speakers if there are multiple speakers, with timestamps if it is a long audio file, and with speakers and timestamps if it is a long audio file with multiple speakers,
.
Once that is done, the transcript will be inserted into the Word document. Confirm that the text is correct and copy it to the website. This will make any audio-only formats much more accessible and in accordance with WCAG standards.
The next subsection of the WCAG standards is the idea that content should be adaptable. This essentially means the content should have the opportunity to be presented in different ways without losing information or structure. This section of the WCAG standards has several techniques to meet the success criterion. One of these techniques is marking the heading as a heading with both role = "heading", and the aria-level. The aria level is way for assistive technologies (AT) to identify the level heading weather it is the h1 heading or an h2 subheading. In HTML, this can look like, <div role = "heading" aria-level = "1">Title of the Article </div> some content. <div role = "heading" aria-level = "2"> Chapter 1</div>. The aria-level headings allows AT to be able to follow the structure of the website. If a change is made to the website, it allows AT to show what the structure of the website originally was, thus allowing the website to be changed without losing any content that was originally built. This fulfills one aspect of the sub requirements of the WCAG standards.
The last subsection of the WCAG perceivable standards is that everything needs to be distinguishable. This allows users to see and hear the content and separate the foreground from the background content. One specific point within this subsection is contrast. What this means is that the text has to have a contrast ratio of at least 7:1 unless it falls into one of the exceptions: Large text, which needs a contrast ratio of 4.5:1, incidental text, and logotypes. For some context, a contrast ratio is a ratio of two relative luminance in the form
where L1 is the relative luminance of the lighter color and L2 is the relative luminance of the darker color. Relative luminance is the relative brightness of a point in a color space, where 0 is the darkest black, and 1 is the lightest white and is calculated with the following formula for the sRGB scale L = .2126*R +.7152 * G * .0722 * B. For example, lets calculate the luminance for yellow (219,239,6) and black (1, 1, 1). The first step is to calculate the relative luminance's. For yellow, L1 = .2126*(219) + .7152*(239) + .0722(6) = 217.9254 and for black, L2 = .2126+.7152+.0722 = 1. Since 217.9754 /1.05 is greater than or equal to 7/1, there is a strong contrast between the two colors and these two colors would be a good example of high contrast colors. Having high contrasts is a good first step in making a website reach the WCAG standards.
Operable
The next section of the standards is the operable standards. This standard is split into five subsections. The first subsection of this standards is that the entire website must be able to function entirely from a keyboard. One piece of this standard is by using the onclick event for anchors and buttons within HTML. The onclick event Is mapped to the default action of a link or button. The onclick event allows an object, such as a button, that typically needs a mouse to click on it to function with the enter or space key on a keyboard. One way that this can be beneficial is a button that runs a script and falls back to a form post for users without script. This approach is designed for sites that do not rely on script if and only if the form post provides the same functionality as the script. The onsubmit = "return false" makes it so the form cannot be submitted. An example of the HTML would look like
<script>
function doStuff() {
//do stuff
}
</script>
<form action="doStuff.aspx" onsubmit="return false;">
<input type="submit" value="Do Stuff" onclick="doStuff();">
</form>
This requirement allows users that may not have the ability to use a mouse be able to fully use a website, allowing for a more accessible site and fulfills a sub requirement of the WCAG standards.
The second subsection of operability is the idea that users should have enough time to read and use the content on screen. One method of stopping this is providing a way for the user to turn the time limit off. This method is a good mechanism for people who are unable to complete tasks within the time limit. This method should be at the top of the page so that it can be found and activated quickly, and it should have the onsubmit setting on so that it can be interacted with both the mouse and the keyboard. This time stopper might be useful on a news site where every minute, a new article appears. This would allow the user to be able to read an article without losing it. It also goes to satisfy one part of the time to read subsection.
The third subsection of the WCAG operable accessibility guidelines handles how to design a website in a way that does not cause seizures or physical reactions. In order to satisfy this section, a website cannot have a light that flashes more than three times in a second. If there are three flashes, ensure that the light dark status at the end of the one second period is the same as the start. This reduces the likelihood that a user will have a seizure on the site and satisfies the sub requirement of the WCAG guidelines.
The fourth subsection of the WCAG operable accessibility guidelines is about ensuring that the website is navigable. There are many different ways that a website can be navigated and ways that the website can be organized. The way that this paper will discuss links back to the section on adaptability. In the adaptability section, the focus was on making sure that the screen reader would be able to identify that a section was a header. The navigability section of the WCAG guidelines focuses on the content of the header. A header does not need to be long, it can be a single word or a couple of sentences. The goal of the header is to clearly show what will be in the content below it. For example, a shorter headline might be, "Accessible Design" while a longer header might be "How to be accessible, an in-depth guide". Both of these header's work for navigability and satisfy one of the sub requirements of the WCAG guidelines.
The last subsection of the operable category is the input modalities category. This category ensures that it is easy to operate functionality through various inputs beyond the keyboard. One such input is a pointer gesture. A pointer gesture is a computer mouse or a touch screen. There are several types of pointer gestures. They include the path-based gesture which is where not only do the endpoints matter, but the way the pointer moves also matters, such as if the pointer goes in a straight line or a curved line. As is starting from one point, moving to a second then going to a third.
These differ from drag gestures as with dragging, the only thing that matters is the start and the end point. It is important that path-based movements be avoided as they can be difficult for users who cannot perform precise movements. One common example of this design is within maps and the pinch-to-zoom features. These features do not outright violate WCAG guidelines, as long as an alternative is present. An alternative to the zoom feature on a map would be a zoom slider in the corner that could be used with the scrolling wheel of the mouse and the arrow keys on a keyboard. When used in conjunction together this specific requirement is met.
Understandable
The next category of the WCAG guidelines is the Understandable requirements. These requirements are centered around the idea that the information and the operation of the user interface must be understandable. This category is split up into 3 parts, Readable, Predictable, and Input Assistance.
The readability sub section focuses on the idea that the text content of a website should be easy to read and understand. One of the requirements in the readable category discusses the usage of abbreviations. Abbreviations may cause difficulties for users who may have difficulty decoding words, rely on screen magnifiers, have limited memory and have difficulty using context to aid understanding. This can be even more difficult when one abbreviation has multiple meanings, such as "Dr. health lives on healthy Dr." In this example, the first Dr. refers to the word Doctor, while the second Dr. refers to the word drive. If a user is zoomed in to a word using a screen magnifier or using AT to understand the text, the meaning might get lost. In order to prevent this meaning from getting lost, it is necessary to explain what the abbreviation means on the page. This could be where the meaning of the abbreviation before the first time the abbreviation appears in content, and a search of all acronyms on the site in an easily accessible location. If an abbreviation has different meanings, an easy solution would be to make the text a hyperlink to the definition of how the abbreviation is being used in that exact instance. This satisfies one sub requirement of the readability requirements.
The predictable subsection focuses on ensuring that the web page is consistent both in its design and the operability of the site throughout all pages of the website. This requirement is heavily linked to the navigation requirements and one of the requirements involve the header mentioned in the previous sections. The requirement in this case is that all components within a website have the same functionality and design throughout the website. Using the header example, all headers should be marked as headers and designed the same way. All body text should be marked the same, have the same font, and the same color. This expands beyond just the text elements, but also applies to the interactive elements of the website as well. For example, if there is a download button there should be a consistent "download logo" next to the button. This ensures that users who use screen readers are easily able to identify what each icon and button does as they are consistent throughout the entire site. This would also satisfy a sub category of the predictability section.
The last subsection within the WCAG understandable section is that the content should have input assistance to help prevent and correct user error. One area that this comes into play frequently is text fields. If a user is asked for a numeric input and the user inserts text, the site might crash or the output might not be what the user asked for. If the user is asked to select their birth day and they are using a screen reader, it is possible that the user misses the year category. A warning that they selected the current year would be helpful in ensuring the user does not make a mistake. This can be helpful for users that might not need AT as well. Many forms ask users to enter their phone number, and there are many different formats that users will default to when entering a phone number. Some user will include a +1. Some users will insert (area code) 123 - 4567, some users will not use the parenthesis. Having this error tracking ensures that there is only one way to enter a phone number into a form for use in the backend and ensures that the phone input is accessible in the front end, satisfying one of the requirements within the input assistance category.
Robust
The last category of requirements is that the content must be robust enough so it can be used with a wide variety of user agents and AT. The main idea of this section is compatibility. When designing a website using standard HTML controls, this category is already largely met, and it is more so targeted for web authors who are developing their own user interface component.
Within HTML, there are many ways that websites can natively be used to communicate with AT. For example, if the website has a link, the AT will pick up if <a href> is used. If the link is in an image, it is possible to combine the link command and the image command, <a href = "wwt.com"><img alt = "WWT " src = "https://www.wwt.com/api-new/attachments/5d409212da02460085a4de2d/thumbnail?width=1200">Headquarters</a> This code will put a link to WWT's homepage inside of a photo to WWT's HQ and the AT will recognize the link and will describe where it goes. This would satisfy the accessibility requirements for this specific link and image.
Conclusion
This post is only the beginning of what makes a website truly accessible. There are so many categories to consider when building accessible sites. These tips are a starting point on the journey to accessibility. To learn more about how WWT can guide your journey to become more accessible and fulfill the WCAG guidelines or 508 website governmental guidelines, please reach out to your WWT account managers.