An Overview of Web Content Accessibility Guidelines (WCAG) and Quick Tips.

Introduction 

This article summarizes the requirements of the Web Content Accessibility Guidelines (WCAG) and should serve as a strong foundation for any developer to ensure that accessibility is included in the design and development of their websites. Furthermore, it provides some first-step technical tips for how to meet these requirements. 

What Are the WCAG Guidelines? 

With over 70 million adults within the United States living with a disability websites must be designed with accessibility in mind. Since 2024, the United States Federal Government has required all governmental websites to meet accessibility standards based on the WCAG, a leading standard for accessibility within websites. There are four categories within WCAG, each with its own subcategories and requirements: perceivable, operable, understandable, and robust. In this article we will walk through one requirement in each subcategory of these guidelines and one approach to satisfy the requirement. This article is not an exhaustive list of all 89 requirements.

Perceivable 

Four subcategories must be met to satisfy the perceivable category. The first requires all non-text content, such as photos, videos, and audio, to have an alternative viewing method (1.1.1). Alternative text is a brief description used by screen readers to convey the content and function of images. This text should fully explain the image's purpose so that no content is lost if only the alternative text is available. Good alternative text should be concise (1-2 sentences), descriptive, and relevant. For example, a bad alternative text for the following image of World Wide Technology headquarters, is "a glass building," since that is too brief and not informative.

Another poor example is a lengthy description detailing every aspect of the photo, which distracts from the purpose of the image and can cause confusion. A better alternative text would be: "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." This version is concise and relevant to the article.  

For large websites with numerous photos, writing alternative text for each non-decorative image can be challenging. AI tools like Microsoft Copilot can assist by predicting suitable alternative text. To use Copilot, upload the photo 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." It's crucial for website designers to review and confirm the AI-generated text for accuracy. Once finalized, the alternative text should be added to the HTML <img src="image path" alt="alternative text"> tag, fulfilling WCAG requirement 1.1. 

The next subcategory of WCAG is time-based media, like video or audio. This type of media is a wonderful way to express ideas and thoughts; however, it is not always accessible. A simple way to make an audio file more accessible is by inserting a choice to view a transcript 1.2.1, which 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. If there are multiple speakers, select with speakers; and if it is an audio file over 5 minutes With timestamps. If it is a long audio file with multiple speakers, select With speakers and timestamps.  

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 increases the accessibility of  audio-only formats in accordance with WCAG standards. 

The next WCAG subcategory emphasizes that content should be adaptable, allowing it to be presented in various ways without losing information or structure (1.3.5). There are several techniques within the WCAG standards 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 a way for assistive technologies (AT) to identify the level heading whether 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 allow AT to follow the structure of the website. If native heading markup is available, i.e. if there are at most 6 levels of headings, using the <hx> content </hx> would also be acceptable. It is not advised to have more than 10 levels of headings within a website.  If a change is made to the website, the overall structure of the website remains documented, assisting in ensuring that the content remains unchanged once the site is reorganized. This fulfills one aspect of the requirements of the WCAG standards. 

 The last subcategory of the WCAG perceivable category is that the content on the website needs to be distinguishable. Users need to be able to see and hear the content and separate the foreground from the background content. One specific point within this subsection is contrast (1.4.6). Text needs 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 contexts, a contrast ratio is a ratio of two relative luminance values 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. Having high contrasts is a good first step in making a website reach the WCAG standards. 

Operable 

The next category of the WCAG standards is operable. This category is split into five subcategories. One requirement is that the entire website must be able to function entirely from a keyboard (2.1.3). One way to satisfy this requirement is to use the onclick event for anchors and buttons within HTML. The onclick event is mapped to the default action of a link or button allowing an object that typically needs a mouse to click on it to function with the enter or space key on a keyboard. 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. 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 who may not be able to use a mouse to fully use a website, fulfilling this sub-requirement of the WCAG standards. 

The second subcategory of operability is the idea that users should have enough time to read and use the content on screen. For example, time stoppers can be useful on a news site where every minute, a new article appears (2.2.2). Stoppers allow the user to be able to finish reading an article without losing it. 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 onclick setting so that it can interact with both the mouse and the keyboard. 

The third subcategory of the WCAG operable accessibility category handles how to design a website in a way that does not cause seizures or physical reactions. To satisfy this section, a website cannot have a light that flashes more than three times a second (2.3.1). 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. 

The fourth subcategory of the WCAG operable accessibility guidelines focuses on is about ensuring that the website is navigable. There are many ways that a website can be navigated and ways that the website can be organized. Linking back to the adaptability section focusing on the ability of the screen reader to identify that a section was a header (1.3.5), the navigability subsection of the WCAG guidelines focuses on the content of that 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 (2.4.6). For example, a shorter header might be, "Accessible Design," while a longer one might be "How to be accessible, an in-depth guide." Both headers work for navigability and satisfy this sub-requirement of the WCAG guidelines. 

The last subcategory of the operable category is input modalities. This subcategory ensures that it is easy to operate functionality through various inputs beyond the keyboard. One such input is a pointer gesture. A pointer gesture uses a computer mouse or a touchscreen. There are several types of pointer gestures. They include the path-based gestures and drag gestures shown in the diagrams below.  

Illustrations of Pointer Gestures (Top) and Path-based Gestures (Bottom) 

Path-based and drag gestures should be avoided (2.5.1, 2.5.7) 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, if 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, these can satisfy this specific requirement.  

Understandable 

The next category of the WCAG guidelines is the understandable requirements, the information and the operation of the user interface must be understandable. This category is split up into 3 subcategories, readable, predictable, and input assistance. 

The readable subcategory focuses on the idea that the text content of a website should be easy to read and understand. For instance, abbreviations (3.1.4) may cause difficulties for users who may have difficulty decoding words, rely on screen magnifiers, have limited memory, or 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." 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. Abbreviations must be defined on the page on which they're used, the meaning of an abbreviation must be given before the first time the abbreviation appears in content, and a search of all acronyms on the site must be provided in an easily accessible location. If an abbreviation has different meanings, use a hyperlink to the definition of how the abbreviation is being used in that exact instance. 

The predictable subcategory ensures that the web page is consistent both in its design and the operability of the site throughout all pages of the website. All components within a website must have the same functionality and design (3.2.4). This requirement is heavily linked to the navigation requirements and involves the use of headers mentioned earlier (2.4.6), (1.3.5).  All headers should be marked as headers, designed the same way, have the same font, and be the same color to satisfy this subcategory 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 errors. For instance, if a user is asked for a numeric input into a text field and the user inserts text, the site might crash, or the output might not be what the user asked for.   Input assistance ensures that there is only one way to enter information into a form for use in the backend and ensures that the input is accessible in the front end. 

Robust 

The last category of the WCAG guidelines is that the content must be robust and compatible with a wide variety of user agents and AT. When designing a website using standard HTML controls, this requirement is already largely met and therefore it is more directed towards web authors developing their own user interface components.  

Within HTML, there are many ways that websites can natively 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 to satisfy the accessibility requirements for this specific link and image. 

Conclusion 

The overview and tips described in this article are only the beginning of designing a truly accessible website. There are many additional aspects to consider. To learn more about how WWT can guide you on your journey to create more accessible websites meeting the WCAG guidelines or 508 website governmental guidelines, please reach out to  WWT today.  
   

Reference 

 Web Content Accessibility Guidelines 2.1, W3C World Wide Web Consortium https://www.w3.org/WAI/WCAG22/quickref 

Abbreviations  

AI = Artificial Intelligence 

AT = Assistive Technology  

HTML = Hyper Text Markup Language 

WCAG = Web Content Accessibility Guidelines  

WWT = World Wide Technology