The #1 question for any site owner is: How can I tell if this web content is actually accessible?
Because accessibility is about human experience, no single tool can give you a “100% Pass” grade. Instead, you use a combination of Automated Scans (to find code errors), Manual Checks (to test usability), and Remediation (to fix issues).
While the University provides enterprise scanning tools for our primary platforms (like Ally in Canvas and DubBot for the main boisestate.edu website), any content living outside these environments requires site owners to perform regular accessibility audits.
Follow the tips on this page for more details on how to get started.
The 3-Step “Accessibility Health Check”
If you are using a platform like Google Sites, a custom research site, or a third-party web platform, follow these three steps to help determine if your content is accessible:
Step 1: Run an Automated Scan
An automated scan is a great place to start because it can give you the big picture of accessibility on your site.
The Goal: Find the “hidden” errors a human eye might miss.
What to look for: Red icons or “Errors.” These are your highest priority. If you have “Missing Alt Text” or “Low Contrast” flags, your site is currently inaccessible to many users.
There are several options but two good places to start are with the Silktide or WAVE browser extensions.
Silktide Browser Extension
Silktide Browser Extension
The Silktide Browser Extension is a great option for non-technical users. It allows you to simulate disabilities (like color blindness or dyslexia) and provides a clean, easy-to-read report of page errors. Get the Silktide Accessibility Checker for Chrome.
Another option is the WAVE Evaluation Tool. This tool adds icons directly onto your live webpage—red for errors, yellow for warnings—so you can see exactly where a heading is skipped or an image is missing text. Get the WAVE Evaluation Tools for Chrome.
These tools offer a deeper look at how a screen reader or assistive device “reads” your site. These tools may not be available everywhere, may require accessing the browsers developer tools, and include more technical information:
ANDI (Accessible Name & Description Inspector): A powerful tool that reveals exactly what a screen reader will announce for every button and link. It’s perfect for ensuring your “Submit” button actually tells the user what it does.
ARC Toolkit: A professional-grade extension that sits in your browser’s “Developer Tools.” it is excellent for finding complex failures in the Big Five and providing code-level advice for fixes.
Lighthouse (Built into Chrome): Found in the “Inspect” panel of Chrome. It provides a high-level “Health Score” for accessibility, performance, and SEO.
IBM Equal Access Toolkit: An open-source, highly detailed checker that follows the full WCAG checklist. It’s excellent for generating formal reports but has a steeper learning curve.
Step 2: Perform Manual Checks
Automated tools can only see about 40% of barriers. To find the rest, you need to test the site yourself using three quick checks:
Keyboard only
400% zoom
Visual contrast
Keyboard Only Manual Check
Keyboard Only
A key measurement of whether your web content is accessible is if you can access everything with the keyboard alone. For this test you only require a keyboard.
Prep: Put your mouse aside and try to navigate your site using only the Tab, Enter, and Arrow keys. We recommend turning your mouse off or physically moving it away from the keyboard.
Goal: Ensure a user who can’t use a mouse isn’t “trapped” in content and can easily access all content in a logical order.
Test: Can you see where you are on the page (the Focus Indicator)? Can you reach every link and button? Can you expand and collapse menus? Can you play, pause, and stop media? If you get stuck in a menu or a video player or can’t access content, you have a Keyboard Trap that must be fixed.
Document and Fix: Note where the issues are so you can work with the platform owner (3rd-party developer) if the problem is in the Theme. If the trap is in your Content—for example, an embedded video player or a complex widget—consider providing a clear, direct link to the source file in addition to the embed.
400% Zoom Manual Check
400% Zoom
Your web content shouldn’t lose features or functions as users zoom. For this text you only require the browsers zoom tool.
Prep: Open webpage in a browser
Goal: Ensure the site “reflows” for users with low vision and for mobile viewing.
Test: To zoom in on a webpage, use keyboard shortcuts or browser settings. The fastest way is holding Ctrl (Windows/Linux) or (Mac) and tapping the key to zoom or using the mouse scroll wheel. Zoom into 400% and review your content. Does the text overlap? Do you have to scroll horizontally to read a single sentence? If the content disappears or breaks, the site “Theme” is not accessible.
Document and Fix: : Note where the layout breaks so you can work with the platform owner or developer. Since “Zoom” issues are almost always related to the site’s Theme (the architecture), this usually requires a technical fix to the CSS or the template itself.
Visual Contrast Manual Check
Visual Contrast
Your web content should be easy to read for everyone, including users with low vision or those viewing your site in bright sunlight. One of the best ways to test contrast is to strip away the color entirely. If your content relies on color to convey meaning (e.g., “Click the green button to start”), that meaning is lost in grayscale.
Prep: Turn on the grayscale setting on your computer. Use the accessibility settings to enable color filters. Windows: Press Windows Key + Ctrl + C (You may need to enable “Color Filters” in Settings > Accessibility > Color Filters first). Mac: Go to System Settings > Accessibility > Display > Color Filters and select “Grayscale.”
Goal: Ensure colors have good contrast, can be read easily, and to find any instances where color alone is used for meaning.
Test: Once in grayscale, can you still tell the difference between the text and the background? Do your “Action” buttons stand out? If everything turns into a muddy gray blob, your contrast ratio is too low. Can you still tell where links are or do they blend into the text? If you have images with text, are they easy to read? Look for any instances where lack of color makes the content difficult to understand.
Document and Fix: Note where the contrast is challenging so you can review your site settings, update content, or work with the platform owner or developer. How you fix contrast issues depends on where the issue occurs. For example, you may be able to adjust your theme settings to change the way links appear. If it is in a document or image you may need to edit the source. If it is in your navigation menus or footers, you may need to contact a developer.
Step 3: Remediate (Fixing the Barriers)
Once you have identified barriers through your scans and manual checks, it is time to take action. Don’t feel like you have to fix everything at once—start with the “Quick Wins” to make an immediate impact on your users’ experience.
Look for Quick Wins
Look for Quick Wins
These are high-impact fixes that often take less than a minute but remove significant hurdles for users with disabilities:
Fix “Click Here” Links: Rename generic links to be descriptive (e.g., change “Click here” to “Download the Research Syllabus”). This helps screen reader users navigate your page’s link list efficiently.
Add Missing Alt Text: Use your platform’s image editor to add a 1-sentence description to meaningful images. If an image is just for decoration, mark it as “decorative” so the screen reader skips it.
Correct Heading Levels: Ensure your page doesn’t skip levels (e.g., going from an H1 title straight to an H3). A logical heading structure is the primary way screen reader users “skim” a page.
Remove “Images of Text”: If you have a flyer or a screenshot of a memo, replace it with actual text. Screen readers cannot read text that is flattened into an image.
Determine the “Owner” of the Issue
Determine the “Owner” of the Issue
If a “Quick Win” doesn’t solve the problem, identify whether the barrier is in your Content or the site’s Theme:
You Own the Content: You are responsible for headings, alt text, link names, text, providing accessible media, and ensuring the documents you upload are accessible. You can fix often these directly in the editor.
The Developer Owns the Theme: If the “Tab” key skips the main menu, or if the site crashes at 400% zoom, this is a Theme issue. Document the issue and contact the platform owner or reach out for additional guidance.
Focus on Progress Over Perfection
Focus on Progress Over Perfection
You may not be able to fix every technical error in a 3rd-party tool or an old Google Site today. Your goal is to remove the biggest barriers first. If a user can navigate your site, read your text, and watch your videos with captions, you have successfully provided an accessible learning environment.
Most Common Document Accessibility Issues
The "Big Five"
On the web, the following areas are often the biggest challenges for accessibility. As a bonus, if your web content has forms, be sure to pay extra attention to them. Learn more about these five areas and how you can build in accessibility from the beginning.