How to find and fix common accessibility barriers
Check images, forms, keyboard controls, media, and enlarged text. Record barriers and verify the fixes.
Start with a task people need to finish
After reading this guide, you'll be able to find the most common barriers on your website, describe what needs to change, and check a fix. A barrier is anything on a page that stops someone from finishing what they came to do. If you're new to the subject, start with our plain-English guide to digital accessibility.
Pick a task such as booking an appointment or sending a request, and follow it from the first page to the confirmation. Most of the checks below need only a browser and a keyboard.
Most barriers are accidents, and most can be fixed. Some fixes belong in your content editor. Others need a designer, a developer, or the company that supplies a tool. For each barrier, record the page, the step, what happened, and what needs to happen instead.
Use a test account or a safe test environment when a task would place an order, send a message, or change real information.
Describe what an image contributes
The barrier: An image carries information that is missing from the text. A screen reader may announce a filename or skip the information entirely.
What to change: Add alt text, a text alternative that conveys the image's purpose in context. A product photo might describe a feature a buyer needs to compare. An image used as a button needs a name that explains the action. Decorative images need an empty text alternative, written as alt="" in HTML, so screen readers can skip them.
How to check: Read the page without relying on its images. Check whether the text still communicates the information and actions. For a chart, provide the important findings and equivalent data in text or a table. A scanner can flag missing alt text, but only a person can judge whether the description fits.
Use W3C's image guidance to choose the right treatment for each image.
Make text and controls distinguishable
The barrier: Faint text is difficult to read. A field marked only by a red border does not explain its error to someone who cannot distinguish that color.
What to change: Choose text and background colors with enough contrast. Check buttons, field borders, icons, and keyboard focus indicators too. Give errors and other states a text label or another clear cue as well as color.
How to check: Measure the colors with a contrast checker instead of judging them by eye. Check normal, hover, focus, and error states. Text on a photograph needs checking against the background behind it, including where that background changes on a small screen.
Our color contrast explanation covers the different thresholds. W3C's contrast requirements explain the text rules and exceptions.
If you’re not sure where to start, tell us about your website and we’ll suggest a first step.
Talk to us about a first stepUse the whole task with a keyboard
The barrier: A menu opens only on hover, a date cannot be selected, or a dialog cannot be closed without a mouse.
What to change: Ask your developer to make each action work with its expected keyboard controls. Use native links, buttons, and form controls where they fit. Keep focus visible and clear of banners that cover it. Provide a way to skip repeated navigation.
How to check: Enable full keyboard navigation in your browser or system settings if needed, then set the mouse aside. Use Tab and Shift+Tab to move between controls. Use Enter or Space to activate controls as appropriate, and arrow keys within controls that use them. Check Escape where it is the expected way to dismiss an open component.
Follow the task through menus, dialogs, errors, and confirmation. You need to be able to see where focus is and to leave any component. A dialog can keep focus inside while open if there is an accessible way to close it. Not every item inside a menu or other composite control needs a separate Tab stop.
If you get stuck, record the component and the keys you tried. W3C's keyboard-trap explanation describes the requirement. Its patterns for interactive controls help developers implement expected behavior.
Give form fields labels and useful errors
The barrier: A field has no clear label, instructions disappear while someone types, or an error message does not say what to correct.
What to change: Give each field a visible label connected to it in the code. Explain required information and any necessary format before someone enters it. Keep instructions available while they type. Identify errors in text, connect each message to its field, and keep the answers that were already right.
How to check: Complete the form using a keyboard. Submit it with a missing required answer and with an incorrect value. Check that you can find the affected field, understand the correction, and try again without re-entering answers that were already right. With a screen reader, check that labels, instructions, errors, and the result are available when needed.
Review the form with your developer using W3C's forms guidance.
Keep sign-in and repeated steps usable
The barrier: Sign-in blocks a password manager or pasting. A process asks for the same information again, or a time limit ends the task before someone can finish.
What to change: Support password managers and copying and pasting credentials. Review authentication steps that require remembering, transcribing, or solving something, and provide the support or alternatives the standard requires. Reuse information already supplied in the same process where appropriate. Review time limits and offer warnings or extensions where required.
How to check: Try signing in with a password manager and by pasting a password. Check any verification step as well as the first screen. Continue through the process and note repeated questions, expired sessions, and lost answers.
WCAG 2.2 adds requirements for authentication and repeated information. Ask your developer to check the exact requirements and exceptions against your sign-in process.
Make audio and video information available
The barrier: A video depends on speech without captions, a podcast has no transcript, or a demonstration shows an important step that nobody describes.
What to change: Provide accurate, synchronized captions for speech and meaningful sounds in video. Provide a transcript for audio-only recordings. Make essential visual information available through the soundtrack or audio description where needed. A transcript does not replace synchronized captions for a video that needs them.
How to check: Watch the video with the sound off and check whether captions convey the audio information. Listen without looking and identify any essential visual information that is missing. Review automatic captions for names, numbers, speaker changes, and timing. Test the player's controls with a keyboard.
Use W3C's audio and video guidance to identify the requirements for your media, including differences between live and recorded content.
Keep content usable when enlarged
The barrier: Enlarging a page hides a button, cuts off text, or forces someone to scroll sideways to read each line.
What to change: Let text resize and layouts adapt. Avoid fixed-height boxes that clip longer text. Keep banners, menus, and form actions from covering content or keyboard focus. Ask your developer to check components at narrow widths and with increased text spacing.
How to check: Enlarge text to twice its usual size. On a desktop browser, also try 400% page zoom and complete the same task. Check a narrow phone layout. Ordinary paragraphs need to stay readable, and every control needs to stay within reach. Content that needs two dimensions, such as a data table, needs its own usable treatment.
Give the developer the viewport size, zoom setting, and affected step. W3C explains text resizing and reflow separately, including their exceptions.
Give the page a clear structure
The barrier: A page has a vague title, long sections without headings, or links whose purpose is unclear when read on their own.
What to change: Use a page title that identifies the content. Use real heading styles in your editor, in a logical order, rather than making ordinary text large and bold. Name a link's destination or action. Use familiar words and explain necessary terms when they first appear.
How to check: Read the headings as an outline. Check that they describe the sections and help someone find an answer. Review link names and instructions. Ask someone unfamiliar with the task to follow them and tell you where the wording leaves a question unanswered.
For documents, provide accessible HTML where practical. A PDF also needs an accessible structure and reading order. Exporting a file that looks tidy is not enough. Review W3C's page structure guidance with the person responsible for templates.
Check fixes and keep a record
Fix the barriers that block essential tasks first, including problems in shared components. Give each finding an owner and a checkable result. After a change, repeat the step that failed and check the rest of the task for new problems.
Use automated testing to catch the problems a tool can detect. Add manual and assistive technology testing, and involve people with disabilities. A clean scan cannot establish that a task is accessible. Our guide to reading a scan or report explains what the numbers mean and what to fix first.
For a small team, an existing task list can hold the page, barrier, owner, fix, and retest date. For a larger organization, record the affected components and supplier responsibilities too. Our guide to how far to take accessibility explains how to organize continuing work.
Your next step: pick one task this week, record the barriers you find, and assign the first fixes. These checks cover only part of the standard, so if you need a full review, talk to us about an evaluation.
Terms used in this guide
Sources
- Easy Checks – A First Review of Web Accessibility
- Images Tutorial
- Understanding Contrast (Minimum)
- Understanding No Keyboard Trap
- ARIA Authoring Practices Guide
- Forms Tutorial
- What's New in WCAG 2.2
- Making Audio and Video Media Accessible
- Understanding Resize Text
- Understanding Reflow
- Page Structure Tutorial
- Involving Users in Evaluating Web Accessibility
- FTC Approves Final Order Requiring accessiBe to pay $1 Million
Get help with every step.
We can work with organizations of every size and industry, from a startup serving its first customers to a bank. We find where you stand, help your team fix what matters, and keep checking as your product changes. That work is evidence of your effort, not a legal guarantee.