My fake website with accessibility errors
This website was presented to me by Austin Community College with intentional accessibility issues to solve. Below is a breakdown of the tools and processes that I used to audit and identify accessibility improvements needed for the site to ensure compliance with the latest WCAG (Web Content Accessibility Guidelines) standards.
Documenting my auditing process
I test using a mix of tools to check whether a website is accessible to all users, including those who rely on screen readers or keyboard navigation. These tools include Lighthouse, VoiceOver,
WAVE, and NVDA. I also included automated accessibility checks using Cypress.io, a programming framework that simulates how users interact with a website in a browser. Once I identify problems, I prioritize them based on their severity and how much they affect the user experience, especially for people with disabilities.
My example spreadsheet to stakeholders
This is an example of the type of accessibility report I might share with stakeholders, tailored to their preferred level of technical detail. It provides a clear summary of identified accessibility issues, including the relevant WCAG criteria, associated guideline levels, descriptions of the issues, their potential impact, and actionable recommendations for remediation.
| Impact | Theme | Item | WCAG Criteria | Level | Description | Items to fix | Fix recommendations | Webpage |
|---|---|---|---|---|---|---|---|---|
| Serious | Color | Text | 1.4.3 Contrast (Minimum) | AA | WCAG AA requires a contrast ratio of at least 4.5 to 1 for normal text. The text for the links on the nav bar have a constrast of 2.47:1. The header over the hero image has a contrast of 1:1. The white text color over the grid body colors of #638475 is 1.66:1. On the contact page, the email link has a contrast of 3.35:1. | 4 | Increase contrast in the nav links and the text over the dark green background images in the grid. Add a shadow around the H1 or darken the background of the hero image. | /intentionally-bad-site.html |
| Serious | Readability | HTML | 3.1.1 Language of page | A | WCAG A requires the default language of each page to be programatically determined. One sufficient way to achieve this is by setting the lang attribute on the html element. This allows braille translation software to substitute and insert control codes as necessary. Speech synthesizers that support multiple language will be also able to adapt to the pronunciation and syntax specific to the langauge of the page. | 2 | Add <html lang="en"> for English to the home page and instead of lang="" on contact.html, replace with en | /intentionally-bad-site.html, /contact.html |
| Serious | Navigation and Orientation | HTML | WCAG 2.4.2 Page Titled | A | WCAG A requires Web pages have titles that describe topic or purpose. Contact.html has a page title of just the name title and the home page does not have a title. | 2 | Add title of "Contact Us - Julie's Fake Company" in contact.html and title of "Julie's Fake Company" in the home page | /intentionally-bad-site.html, /contact.html |
| Moderate | Structure & Semantics | Headings | WCAG 1.3.1 Info and Relationships | A | As noted in technique H42, headings are used in a hierarchical layout with h3 as a subsection of h2, which is a subsection of h1. Skipping heading ranks can be confusing and should be avoided where possible as this can confuse screen readers. Additionally multiple h1s should be used in a meaningful hierarchy, such as in different sections of a page. Headings at the same level should all be consistent. | 3 | Change "Discover America's Story" from h1 to h2. This resolves the fact that there are multiple h1s on the home page and provides the correct nested hierarchy. In contact.html, consider changing the "Contact me" to H1 so that the page does not begin with an H2. Change the heading for Arches National Park to h3. | /intentionally-bad-site.html |
| Minor | Readability | Text | WCAG 1.4.4. Resize Text | AA | Font size should not be below 12px for secondary content. This is not a WCAG guideline but this was flagged by WAVE. | 1 | Increase font size in footer from 10px to 12px | /intentionally-bad-site.html, /contact.html |
| Critical | Structure & Semantics | Images | WCAG 1.1.1- Non-Text Content | A | Using something like alt="image" or alt="chart" fails to convey the actual purpose or content of the image | 4 | Change the alt text of the national park images to reference the park in the image. Add alt text to the social media icons. | /intentionally-bad-site.html |
| Moderate | Interactions | Links | WCAG 2.4.7 Focus Visible | AA | Buttons do not have a visible focus state, making it difficult for keyboard users to navigate | 1 | add a visible :focus style to the css, maybe adding a outline or changing the background-color | |
| Moderate | Interactions | Links | WCAG 2.4.7 Focus Visible | AA | Navigation links do not have a visible focus state, making it difficult for keyboard users to navigate | 2 | add a visible :focus style to the css, maybe adding a outline or changing the background-color | |
| Serious | Forms and Input | Form | WCAG 2.5.3 Label In Name | A | The id of the name input is "input" and the id of the email input is "input". The ids should match the names, which are name and email respectively. Because the names do not match the visible labels, assistive technologies such as screen readers may not associate the visible label with the correct corresponding field. | 2 | Change id of name to "name" and email to "email" | /contact.html |
| Minor | Forms and Input | Form | WCAG 1.3.5 Identify Input Purpose | AA | For input fields, this WCAG rule requires that content is implemented using the correct supporting technologies. WCAG uses a fixed list of labels (called “tokens”) including email to use autocomplete on and this list includes email. | 2 | Add autocomplete="name" and autocomplete="email" to the form fields | /contact.html |
| Serious | Forms and Input | Form | WCAG 1.3.1 Info and Relationships | A | A technique referenced in WCAG 1.3.1 says that programmatic indication of a form field as mandatory for success of the form. | 2 | Indicate the field is required using an asterik which is associated with required fields. Indicate the field is required on submission if empty by surrounding the field with a red border around the field via CSS using ::after. Use required or aria-required in the attributes. | /contact.html |
| Serious | Forms and Input | Form | 3.3.2. Label or instructions | A | The label element's for attribute must match the id attribute of the input element. Also each input field must have an attribute. | 3 | Because the labels on the contact page do not have a "for" attribute, they appear to screen readers as orphaned labels and not associated to the appopriate fields. The textarea also needs a label with a correct attribute. | /contact.html |
| Moderate | Forms and Input | Form | 3.3.3 Error Suggestion | AA | If an input error can be detected and suggestions for correction are known, then the suggestions should be provided to the user and the error should be provided to the user in text. | 1 | Create error messages in javascript. When the user enters an invalid email in the email field or an empty field for name, it should trigger the correct error message for the field. That error message should also receive keyboard focus and should disappear on entry of a valid value. This also requires that the name is changed to a required field. It is also best practice to include an error notification in the page title since a screen reader user is likely to believe the page was submitted correctly. | /contact.html |
| Moderate | Forms and Input | Form | 4.1.3 Status Messages | AA | Status messages should be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without using focus. The user should know the success or result of an action including the waiting state of an application. | 1 | A feedback message should display on the screen confirming the submission of the form is successful when submitted with no errors. This can be done by adding role="status" to an area near the form. | /contact.html |
| Moderate | Navigation and Orientation | HTML | 2.4.5. Multiple Ways | AA | There should be more than one way to locate a Web page within a set of Web pages. Currently, there is only one way to navigate to the contact page from the index page | 1 | There should be at least two ways of reaching the same content. One way would be to reproduce the menu of nav items in a site map in the footer. | /intentionally-bad-site.html |
| Moderate | Structure & Semantics | Buttons | 2.4.6 Headings and Labels | AA | Headings and labels must correctly describe their topic or purpose. The submit button for the form says "Click". This is a generic verb that doesn't tell the user or screen reader what will happen and doesn't convey purpose. The national parks link on the home page use h3 for most headings but use h2 for another heading at the same level. The headings must be consistent. | 2 | Change "Click" for submitting the form to "Submit". "Click Here" in the home page should be replaced with a more descriptive verb. | /intentionally-bad-site.html, /contact.html |
| Moderate | Structure & Semantics | Links | 2.4.6 Headings and Labels | AA | Headings and labels must correctly describe their topic or purpose. The national parks link on the home page use h3 for most headings but use h2 for another heading at the same level. The headings must be consistent. | 1 | Change the h2 heading to h3 for Arches National Park. The heading should not be underlined. | /intentionally-bad-site.html, /contact.html |
| Moderate | Navigation and Orientation | Navigation | 3.2.4 Consistent Identification | AA | Components with the same functionality in a web site that appear repeatedly are identified consistently. A strategy that people who use screen readers use when operating a website is to rely on familiarity with functions with similar labels or accessible names. Confusing and mismatched labels will increase the cognitive load for people with cognitive limitations. | 2 | Change the contact 'button' to a link as is consistent with the other nav items. Although the image alignment does not directly violate the WCAG guidelines, it is at least best practice for these similar images that are postioned next to each other to have similar alignments. | /intentionally-bad-site.html, /contact.html |
| Minor | Interactions | Links | 2.5.5. Target Size | AAA | Custom targets should be at least 44x44 pixels. Smaller targets will be too difficult for users with hand tremors, limited dexterity, or other reasons such as using public transportation which may shake. If the target is too small, it may be difficult to aim at the target. Users who have to use their fingers instead of a mouse or stylus lack the same level of fine control they would get from these devices. | 1 | Change the social media icons from 20x20 to at least 44x44 with an increased gap between the icons. | /intentionally-bad-site.html, /contact.html |
| Moderate | Responsive design | HTML | 1.4.10 Reflow | AA | Content must reflow so it can be presented without loss of information or functionality and without requiring scrolling in two dimensions | 4 | Fix hero h1 which is set to 80px font, the social imgs which are set at 20 x 20, footer text is set to 10px, and the nav a which has no wrap. The textarea message box in contact also can be expanded horizontally to overflow the screen. | /intentionally-bad-site.html, /contact.html |
| Moderate | Navigation and Orientation | HTML | WCAG 1.3.1 Info and Relationships | A | Information, structure, and relationships conveyed through presentation can be programatically determined or are available in text | 2 | Add landmarks such as <main> and <footer> (instead of class being footer on a div), which can help screen readers navigate the page. | /intentionally-bad-site.html, /contact.html |
My example report to stakeholders
This is an example of the type of report I would share with stakeholders. Once I have documented the accessibility failures in a spreadsheet, I use pivot tables and charts to summarize and visualize the data, helping non-technical audiences quickly understand the scope and impact of the issues. My final report with clear and actionable recommendations is designed to support collaboration, raise awareness, and drive positive change.