Is Your Site Accessible? Five Simple Tests

Test 1: Turn Off the Graphics

When a visitor visits a page that relies on visual cues, the experience can crumble the moment those cues are stripped away. Turning off images forces a test that mirrors how assistive technologies interpret content. Start by accessing your site in the browser you use most often. In Chrome, click the three‑dot menu, select Settings, go to Privacy and security, then Site Settings, and under Images choose “Don’t show images.” Safari users can enable the “Disable Images” option via the Developer menu. Firefox follows a similar path: Options → Privacy & Security → Permissions → Images → Block all external images. Once images are hidden, refresh the page. If navigation fails, forms break, or information becomes unintelligible, you’ve hit the first red flag. Every graphic that conveys meaning - logos, icons, charts, and especially navigation buttons - needs an alternative text descriptor that tells a screen‑reader user what the image represents. The alt attribute should be concise and descriptive, such as “Search icon” or “Download PDF.” For purely decorative elements, use an empty alt value (alt="") so screen readers skip them and do not clutter the user’s experience. If you employ image maps, each area tag must have its own alt text. When in doubt, ask: could a blind user understand the purpose of this visual by hearing a description?

When you find missing or inadequate alt tags, patch them up before moving on. In addition to improving accessibility, alt text fuels search engines, allowing them to index the visual content that would otherwise be invisible to crawlers. A properly tagged image also supports the semantic structure of your page, which is vital for assistive devices that rely on the Document Object Model. If a navigation button is presented as an image with no alt, a blind user might never learn that the image is clickable, leading to frustration and abandonment. Consider adding a small aria-label to interactive images or wrapping them in button elements, giving both screen readers and browsers a clear cue that the element performs an action.

Beyond alt text, think about how you structure your visual hierarchy. Using CSS backgrounds to display icons or decorative patterns keeps the markup clean and allows the browser to skip or download only what’s necessary. Whenever you use a graphic that’s essential to the function of the page, provide an alternative that can be accessed via text. This might mean adding a hidden span with the same content or duplicating a link that is visually hidden but remains in the tab order. By ensuring every image has a corresponding textual representation, you set a strong foundation for the rest of your accessibility checks.

Finally, test your changes with a real screen‑reader if you have access. NVDA for Windows or VoiceOver on macOS can read the page aloud, revealing any gaps in the textual descriptions. Even a simple review of the page source after disabling images can confirm that every img tag is accompanied by a meaningful alt attribute. When you’re confident that the site still makes sense without its graphics, you’ve successfully cleared the first hurdle in your accessibility journey.

Remember, the goal isn’t just to make the site usable in a grayscale world - it’s to create an inclusive experience that serves everyone, regardless of how they perceive the web. The steps above are straightforward, but they carry long‑lasting benefits for users, search engines, and compliance frameworks alike. Once you’ve addressed the image layer, move on to the linearization test that follows.

Test 2: Copy Your Site Into Notepad

Copying a page’s HTML into a plain‑text editor is a low‑tech method that reveals the underlying reading order - a critical factor for screen‑reader navigation. Open the page in a browser, select all content with Ctrl + A (or Command + A on macOS), and copy it. Paste the data into Notepad, TextEdit in plain‑text mode, or any other editor that strips formatting. The result is a linear dump of the page’s textual content, free of CSS, images, and interactive elements. If you are a blind user, a screen reader follows a similar path, reading elements in the order they appear in the DOM. The copy‑paste test is a quick sanity check: does the text flow logically from start to finish? Are headings properly ordered? Does the narrative make sense without the visual layout that typically guides readers?

When you review the plain‑text output, pay close attention to the placement of key elements such as navigation menus, form labels, and headings. If the menu items appear after the main content, a user who relies on keyboard navigation or a screen reader will be left searching for the site’s structure. Misordered elements can cause confusion and frustration. The remedy is often a simple restructuring of the markup: move the nav element higher in the DOM, or insert landmark roles like role="navigation" to give assistive tools a clear cue. For content that logically belongs in the header, ensure it appears before the main article text.

Another common pitfall is the misuse of tables for layout. While tables may align columns visually, they impose a tabular reading order that a screen reader interprets as rows followed by columns. This can scramble the logical sequence of information. Replace layout tables with CSS flexbox or grid, and keep real data tables limited to tabular data that benefits from a spreadsheet‑like structure. If you must use tables for genuine data, add the summary attribute to describe the table’s purpose, and use proper th elements for header cells so that screen readers announce them appropriately.

Check that all interactive elements have descriptive labels. Buttons that rely on text within images must have a visible aria-label or an adjacent label element. For form fields, the label tag should wrap the descriptive text and point to the corresponding input via the for attribute. When you paste into plain text, you’ll see whether each label appears before its field; if it does not, the association is broken, and a screen‑reader user may not know which field the label refers to. Adding proper semantic markup - headings, lists, blockquotes - helps the linearized view make sense and improves the overall accessibility of the page.

Once the text feels coherent, run a quick screen‑reader test. Use NVDA or VoiceOver to navigate the page and observe whether the order matches the plain‑text version. If you notice discrepancies, tweak the HTML and re‑copy into Notepad until the linear sequence aligns with the visual flow. A consistent reading order not only satisfies users with disabilities but also enhances your site’s SEO, as search engines now better understand the hierarchy and relationships within your content. After this linearization check, you’re ready to examine how your site handles color and contrast.

Test 3: View Your Site in Black and White

Printing a page in black and white or disabling color in the browser is a simple yet powerful way to expose color‑dependent design choices that may hinder users with visual impairments. When you remove color, any contrast that relied solely on hue becomes flat gray. A headline that was blue against a white background may now appear washed out and difficult to read. Likewise, a button that only changes color when hovered over loses its visual cue, making it harder for users who cannot see color changes. By printing or forcing a monochrome view, you discover whether your design can survive without color, a condition that affects not only the color‑blind community but also users who view content in low‑light conditions or with older hardware.

Start by printing the page or using a browser extension that simulates a grayscale output. In Chrome, open DevTools (F12), click the “Toggle device toolbar” icon, and then choose “More tools” → “Rendering” → “Emulate CSS media: color.” In Safari, enable the “Show Develop menu” from Preferences, then choose “Show Web Inspector” and go to the “Styles” tab. After the grayscale rendering, scan the page for any text that is now hard to read. If the contrast between the foreground and background falls below the WCAG minimum of 4.5:1 for normal text, you need to adjust either the text color, background color, or font weight. Tools like the Vischeck. Paste the URL or upload a screenshot, and the tool will generate images that mimic how a user with protanopia, deuteranopia, or tritanopia would see your content. Review the results for any text or key graphics that become indistinguishable. If you find a problem, modify the palette to use colors that contrast across all vision types. The WebAIM Color Contrast Analyzer can help you pick accessible color combinations. Remember, the goal is to make sure that color is a supplementary cue, not the sole source of meaning.

After adjusting your color scheme, revisit the plain‑text test to confirm that the visual changes haven’t introduced new layout issues. A well‑designed monochrome version not only benefits users with color vision deficiencies but also improves readability for those who prefer dark‑mode or have low bandwidth connections where color data can be trimmed. This step completes the visual accessibility sweep, leaving the next challenge: ensuring your site remains functional without CSS.

Test 4: View Your Site Without Your Style Sheet

Removing the external stylesheet is a decisive test of whether your page relies too heavily on CSS for its basic structure. Move the CSS file to a separate folder or temporarily rename it, then refresh the page. If the layout collapses into a single column, the headings and paragraphs reflow correctly, and users can still navigate the content, you’ve built a solid foundation. However, if the page becomes a jumbled mess - headers floating, navigation hidden, or text too small - your site is too dependent on styles that may not load for some users. In that scenario, consider adopting a progressive enhancement strategy, where core content is delivered first and styles are layered on top to improve the experience for those with modern browsers.

Examine the page to see if interactive elements still work. Buttons should remain clickable, forms should submit, and links should navigate even when styles are missing. A common pitfall is using the deprecated <font> tag or inline style attributes to set font families and sizes. Those declarations prevent a screen reader or a user who has overridden the default font size from adjusting the text, thereby impairing accessibility. Switch all font settings to CSS rules in the external stylesheet and allow the user agent to apply them. This way, if the stylesheet fails to load, the browser will fall back to the default serif font at a readable size.

When you encounter elements that disappear or become invisible without CSS, you’re dealing with content that’s been hidden behind display properties. The display:none; rule removes elements from the document flow and from the accessibility tree. If you truly need to hide content for visual reasons, use visibility:hidden; or position the element off-screen with position:absolute; left:-9999px;. These techniques keep the content in the DOM, allowing assistive technologies to access it. Never rely on color or opacity to hide text, as that creates a security risk and violates accessibility guidelines.

Another area to review is the use of CSS for layout. Avoid relying on absolute positioning to stack elements, as that can break when the viewport changes or when styles are absent. Instead, use semantic HTML - headers, lists, sections, articles - and let CSS manage the visual presentation through flexbox or grid. This separation of concerns ensures that the page remains usable when CSS fails or when a user prefers a simpler view, such as in a text‑only browser or a screen reader.

Finally, check that the page’s typography remains legible without CSS. If the default font size is too small, users may struggle to read the text. The WCAG guideline recommends a minimum of 16 pixels for body text. By setting a base font size on the html element - e.g., html {font-size: 100%;} - you provide a solid fallback that users can scale. Coupled with a responsive design that adapts to different screen sizes, this approach safeguards readability across all devices. Once you’re satisfied that the site functions and reads well without styles, you’ve passed the fourth test.

Test 5: Unplug Your Mouse

Keyboard navigation is the backbone of accessibility for users who cannot use a mouse. To verify that your site is fully navigable without a pointing device, simply turn off your mouse or unplug it from the computer. Now, rely on the Tab key to cycle through interactive elements, Arrow keys to navigate within form fields or menus, and Enter or Spacebar to activate links and buttons. If you find that the focus jumps unexpectedly, skips critical sections, or lands on non‑interactive elements, the tab order is broken and needs adjustment.

Focus outlines should be visible and distinct; many sites turn off outlines to achieve a cleaner look, but that leaves keyboard users blind to where they are. Restore focus styles or add a custom one that remains visible even when users resize text or use high‑contrast themes. The WCAG guideline states that focus must be apparent for all interactive elements. Test by navigating through the page and ensuring that each link, form control, and button highlights clearly.

Menus present a particular challenge. Hover‑over dropdowns or mega‑menus that only reveal themselves when a pointer moves over an item are unusable for keyboard users. Ensure that menus are accessible via the keyboard by assigning proper ARIA roles such as role="menubar" and role="menuitem". Also, provide a skip link at the top of the page - typically “Skip to main content” - so users can bypass repetitive navigation. If a site relies on a JavaScript plugin for menus, verify that the plugin includes keyboard support or add an alternative text‑only menu that loads if scripts are disabled.

Form fields should have labels that are programmatically associated with the inputs via the label for="id" pattern. This association lets screen readers announce the field’s purpose when the user focuses on it. If you use placeholders as the only hint, it creates a barrier because placeholders disappear once the user starts typing. Combine placeholders with visible labels for clarity. When you test with a keyboard, move into each input and confirm that the label reads correctly. Also check that the form’s submit button is reachable and labeled appropriately.

For users who rely on keyboard shortcuts, consider adding Ctrl+Alt combos to jump to key sections, such as the search bar or navigation. These shortcuts should be documented in the site’s help section. Remember that not all assistive technologies respond to custom shortcuts, so keep the primary navigation accessible through standard keyboard actions.

After a thorough keyboard test, you’re ready to consolidate your findings. A site that passes all five tests - graphics, linear order, color, styles, and keyboard navigation - offers a robust foundation for inclusive design. While no single set of checks guarantees full compliance, these practical steps significantly improve usability for people with visual, motor, or cognitive disabilities. For deeper dives, consult resources such as Center for Applied Special Technology for tools like CAST Bobby, which can automatically flag major accessibility barriers. By embracing these tests, you not only comply with emerging legal standards but also unlock a wider audience and elevate the overall quality of your web presence.