An Exercise in Accessibility

For a recent module in my instructional technology coursework, I was asked to take a two-page Word document about orchards and vineyards and perform an accessibility audit. Upon initial inspection, it looked fine. It had readable text, a couple of nice photos, and a tidy source list. After running it through an accessibility checker and reviewing it several issues were discovered. Many of the issues are common enough that I catch them in documents I receive from colleagues almost every week. I annotated the original file with comments explaining each problem, then rebuilt it into a corrected version. Below is a side-by-side look at both pages, along with what I found and why it matters for anyone reading with a screen reader, low vision, or cognitive disability.

Page 1: Headings, Alt Text, Captions, and Title

The first page had four issues stacked on top of each other. Most fundamentally, the document had no headings at all: the section titles were just bold, larger text, which looks like a heading but isn't tagged as one. Word's Navigation pane made this obvious, reporting that the document had no headings, which means screen reader users have no way to jump between sections or build a mental map of the page. Sighted users can scan documents visually, while users with vision impairments who use screen readers will miss out on the ability to scan your document without the explicit use of headings.

The image alt text was even more revealing. Instead of a description, it read as a raw file path, leftover metadata that Word pulled in automatically when the image was pasted in. A screen reader reads that entire string aloud, which is worse than having no alt text at all. I also flagged the caption underneath the orchard photo: captions are optional and written for sighted readers, but they are not a substitute for descriptive alternative text, since screen readers don't reliably announce captions the way they announce alt text. Finally, the document's own Title field was blank, so a screen reader announces the file name instead of a real title, and the colored text throughout didn't meet WCAG's minimum contrast ratio against the background.

Page 2: Contrast and Reference Links

Page two carried two more issues. The same insufficient-contrast problem repeated in the body text, a reminder that contrast failures are rarely one-off; once a color choice is baked into a document, it tends to repeat. And the References list used bare, unformatted URLs. This one is a genuine gray area: screen readers read raw URLs character by character, which is tedious and meaningless to listen to, so links should normally use descriptive text instead. But source lists are the accepted exception, since readers expect a References or Works Cited section to show the actual URL, so I left those as-is while confirming the same pattern didn't show up anywhere else in the body text.

Language & Title Checks

Two smaller checks rounded out the review: confirming the document's language was correctly marked, since Word can auto-detect this but it's worth verifying by hand, especially in mixed-language files, and double-checking the Title field under document properties, which is often the very first thing writers forget to set.

None of these issues is novel. They are the same handful of problems that appear time and again: missing headings, meaningless alt text, poor contrast, and an empty title field that show up in almost every document I review. Catching them takes a few extra minutes. Fixing them is the difference between a document some people can use and one everyone can.

Principles That Guide Accessible Design

Most accessibility requirements trace back to the same four-part framework: content must be perceivable, operable, understandable, and robust, commonly abbreviated as POUR in the Web Content Accessibility Guidelines (King & Piotrowski, 2021). Perceivable content offers a non-visual equivalent for anything visual or audible: alt text for images, transcripts for audio, captions for video. Operable means every function works from a keyboard alone, without relying on a mouse, a timer, or a gesture. Understandable content declares its language, follows predictable navigation, and uses a heading structure that mirrors the page's organization. Robust content is coded cleanly enough that current and future assistive technology can parse it correctly.

One item I thought might make a good addition to this challenge is including some text in a different language. I suppose this could be easily added by including the genus and species of a particular plant, which are usually in Latin. Screen readers will use the declared language to customize the pronunciation of text in other languages.

Attending to accessibility concerns is not just a best practice. Doing so carries legal weight. Title II and Title III of the ADA, Section 504 of the Rehabilitation Act, and Section 508 all treat inaccessible digital content as a form of discrimination, and courts have increasingly read a "place of public accommodation" to include websites, not only physical buildings (King & Piotrowski, 2021). Harvard's 2019 consent decree over inaccurate video captions and the broader shift toward WCAG 2.1 AA as the legal standard are reminders that these guidelines are not abstract suggestions. They are the minimum expectations to which institutions are now held (King & Piotrowski, 2021).

Tools and Methods for Finding Barriers

Finding these problems takes more than a glance at a rendered page. Automated scanners like WAVE flag likely violations by overlaying icons onto a page and sorting findings into "errors," near-certain violations, and "alerts," issues worth a closer look, which is roughly the approach behind the Word document review that anchors this post (Huss, 2022). But automated tools only catch what their code is built to catch. Huss (2022) found that the WAVE tool identified only around 62% of the errors that a thorough manual review would find. This is why manual testing with an actual screen reader, NVDA, JAWS, or VoiceOver, is still the more reliable check, especially for anything interactive (Rybin Koob et al., 2022).

Though very challenging, I recommend to my colleagues that they unplug the mouse and try to complete the same task using only keyboard interactions. Anything unreachable that way will not be reachable for someone using a keyboard or switch device either (Rybin Koob et al., 2022). Built-in checkers can help too. Word's Accessibility Checker can flag missing alt text, unclear hyperlinks, and heading problems directly within the document, using the same workflow as the one used to annotate the orchards-and-vineyards file above. It should be noted that the Word accessibility tool found only one issue with the document: insufficient contrast in the red text. It did not check the quality of the alt text, just the presence.

Common Barriers

The same list of common problems keeps resurfacing, which is reflected in research. Huss (2022) found alt-text errors accounted for the largest single category of violations across 600 high school homepages. This mirrors what showed up in the exercise document used in this assignment. Alt text that describes a file location instead of a picture's content does not meet the purpose of alt-text. Empty or vague links, missing form labels, and low color contrast rounded out the most common errors in that same study (Huss, 2022).

Interactive classroom tools introduce their own barriers. Rybin Koob et al. (2022) tested five tools used in library instruction and found that unlabeled buttons, timers that interrupt a screen reader mid-sentence, and inconsistent "focus handling," where a screen reader's attention does not move to new content on screen, were common enough to block a blind student from completing a task altogether in several of the tools. For learners who are deaf or hard of hearing, barriers show up in other ways. Harvard's 2019 settlement centered on inaccurate video captions, a reminder that captioning must be accurate, not just present, to satisfy WCAG 2.1 AA (King & Piotrowski, 2021).