Accessibility can feel complicated. We make it easier.
Web accessibility means websites, tools, and technologies are designed so the most people can use them. This includes being able to see, hear, navigate, and understand content in different ways.
WCAG is a set of guidelines from the W3C (World Wide Web Consortium) that explains how to make web content more accessible.
“AA” is a middle level of accessibility requirements. To meet WCAG Level AA, you must meet all Level A and all Level AA success criteria.
Most organizations aim for WCAG Level AA (not just Level A) because Level A is the minimum. It fixes the most basic barriers, but it can still leave many people unable to use parts of a website.
Level AA goes further and covers common, real-world needs—like color contrast, clearer error messages, and more consistent navigation. Because of that, AA is widely treated as the practical “baseline” for accessibility work.
In short: A is a starting point. AA is the level that usually makes a site usable for more people.
In many cases, yes. In the U.S., the Department of Justice has said the ADA applies to state and local governments and public accommodations, and accessibility helps more people use online services. Requirements can depend on your organization and risk level, so it’s smart to get guidance for your situation.
The best way is to do an accessibility test. You can start with quick checks, but a real evaluation includes both automated testing and manual testing (keyboard and screen reader checks).
If you want an easy place to start, try Unity QuickCheck, our free Chrome extension. It guides you through automated checks and helps you spot common accessibility issues right in your browser.
Manual testing is when a real person checks a website or web app for accessibility issues using WCAG 2.1 AA and WCAG 2.2 AA. It works alongside automated scans. Automated tools are helpful, but they can’t catch everything. Manual testing helps confirm whether the site is truly usable for people who use a keyboard or assistive technology like a screen reader.
Manual testing often checks things like:
- Can you use the site with a keyboard only?
- Does a screen reader read the page in a clear, helpful way?
- Is the focus easy to see as you tab through the page?
- Are forms labeled correctly, with clear instructions and error messages?
- Do links and buttons make sense without extra context?
Manual testing follows a clear set of steps. The exact details can vary by website, but the process usually includes:
Confirm what will be tested
Choose the pages and tasks that matter most, like navigation menus, login, search, and forms.
Test with keyboard only
Move through the site without a mouse to make sure you can reach and use every control.
Check visual and interaction issues
Look at color contrast, text resizing, layout changes, and click or tap target size (including WCAG 2.2 updates).
Check focus and reading order
Make sure the tab order is logical and the focus indicator is easy to see.
Test with a screen reader
Check that headings, buttons, links, and form fields are announced clearly and in the right order.
Review forms and error messages
Confirm labels are connected to fields, required fields are clear, and errors explain what went wrong and how to fix it.
Check page structure and content
Review headings, lists, tables, and link text to make sure the content is organized and easy to understand.
Write down results and match them to WCAG
Document what passed, what failed, and which WCAG 2.1 AA or 2.2 AA rule each issue relates to.
Testing is finding accessibility problems in your website, documents, or product by testing them against accessibility rules (like WCAG) and write down what’s not working and why.
Remediating is fixing those problems. It means making changes to the code, content, design, or documents so people can use them more easily.
In short: testing tells you what’s wrong; remediating makes it right.
It depends on the size and complexity of your site, how many page types you have, and which user flows need testing. Many teams test a sample of key pages and templates instead of every single page, then expand testing as needed.
Overlays and widgets do NOT fix the underlying accessibility problems in your code and content. They can interfere with assistive technology and create new problems while leaving the original issues unfixed. They also give you a false sense of being compliant.
Still have questions?
Tell us what you’re working on and we’ll point you to the right next step.