How to Review a Web App for Accessibility for the First Time

A first accessibility review can feel big.

You open a web app. The screen looks finished. The buttons work with a mouse. The form submits. The layout matches the design closely enough. Then someone says, “Can you check it for accessibility?”

That is where a lot of people get stuck. They may understand that accessibility matters. They may have heard of WCAG. They may know there are tools that can scan a page. But when they are looking at a real screen, it is not always obvious what to do first.

This guide is meant to help with that first pass. It will not make you an accessibility expert overnight. It will not replace formal accessibility review, disabled user feedback, or deeper assistive technology testing. It also should not be treated as a guarantee that a product is fully accessible.

A first review should help a team catch common issues earlier, ask better questions, and document findings clearly enough that someone can act on them. That matters because many accessibility problems are not mysterious. They show up in ordinary web app patterns: forms, buttons, links, modals, menus, search results, filters, dashboards, tables, error messages, and confirmation pages.

Once you learn how to look at those patterns, you start seeing the same issues earlier in the work.

Who this guide is for

This guide is for people close to the work who need a practical way to review a screen before it gets too expensive to change.

That may include:

• A BA checking whether acceptance criteria are clear enough to test
• A tester doing a first pass before a formal review
• A developer checking whether a component behaves the way it appears to behave
• A product owner trying to understand whether a user can complete the main task
• A delivery lead trying to reduce late rework

You do not need to be the final accessibility authority to help. You just need enough understanding to catch common issues and write them down in a useful way.

A first pass does not replace deeper review. It reduces preventable surprises.

What a first review is trying to do

A useful first review is not random issue hunting. It starts with the user’s task.

Before checking individual controls, ask:

• What is the user trying to do on this screen?
• What is the main path they need to complete?
• What mistakes are likely?
• What information do they need before they act?
• What happens when something goes wrong?

This keeps the review grounded in the actual experience. Otherwise it is easy to jump straight into tool output or isolated checklist items and miss the bigger problem: the user may not be able to complete the task.

A simple first pass can move through this path:

1. Identify the user goal.
2. Try the main path.
3. Try the same task with the keyboard.
4. Check structure, labels, buttons, links, and controls.
5. Trigger errors and check recovery.
6. Check zoom and reflow.
7. Write findings clearly enough for someone to reproduce and fix.

That path is not the whole review. It is a way to stay oriented. The detailed guide below expands the same path with forms, assistive technology clues, contrast, focus visibility, dynamic content, tool use, and prioritization.

Step 1: identify the user goal and main path

Start by naming what the user is trying to do.

For example:

• Create an account
• Sign in
• Search for a record
• Filter a list
• Update contact information
• Review and submit an application
• Download a document
• Open a message

This sounds simple, but it changes the review. You are not only asking, “Does this page have accessibility issues?” You are asking, “Can a person complete this task when they use the page in different ways?”

A user goal also helps you decide what matters most. If the page has a decorative icon with low contrast, that may be worth noting. But if a required dropdown cannot be operated with a keyboard, that blocks the task. The main path gives you a practical sense of priority.

For a first review, write down:

• The screen or flow you reviewed
• The main user goal
• The primary actions the user must take
• The likely error paths
• Any repeated components that appear across the app

Repeated components matter because one issue can become many issues. If the same inaccessible dropdown appears on every form, that is not just one screen problem. It is a pattern problem.

Step 2: review the page structure

Before focusing on individual buttons and fields, look at the page as a whole.

Can someone understand where they are and what the page is for?

Check for:

• A page title that describes the current page or task
• One clear main heading
• Headings that create a meaningful outline
• Sections that match the user’s task
• Instructions that appear before they are needed
• Repeated navigation or content that does not get in the way of the main task
• Visual headings that are actually marked up as headings, not only styled text

This is one of the places where visual understanding and programmatic structure can drift apart.

A page may look organized because the design uses large bold text. But if that text is not marked up as a heading, someone navigating by headings may not get the same structure. A form may look grouped visually, but if fields are not grouped or labeled clearly, the relationship may be harder to understand with assistive technology.

For a first pass, you do not need to inspect every line of code. But you should get in the habit of asking whether the visible structure is also available to people who do not experience the page visually.

A practical way to check:

• Look at the visible headings.
• Use a browser extension, accessibility tree, or screen reader heading list if available.
• Compare the two.
• Ask whether the outline would still make sense without the visual layout.

Example:

Good outline:

• H1: Update mailing address
• H2: Current address
• H2: New address
• H2: Review changes

Problem outline:

• H1: Home
• H4: Update mailing address
• H4: Current address
• H2: Submit

The second outline may still look fine on screen. But structurally, it is confusing.

Step 3: test keyboard access

Keyboard testing is one of the most useful first-review habits.

Put the mouse aside. Use the page with:

• Tab (tab forward)
• Shift+Tab (tab backward)
• Enter
• Space
• Arrow keys where expected
• Escape for dialogs and menus where expected

Try to complete the main task.

Look for:

• Can every interactive control receive focus?
• Is focus visible?
• Does focus move in a logical order?
• Can buttons, links, fields, dropdowns, menus, and modals be used?
• Does focus get trapped somewhere it should not?
• Does focus move behind a modal while the modal is open?
• When a modal closes, does focus return to a sensible place?

This test often reveals issues quickly because many web apps are designed and reviewed with a mouse first. If the screen only works when someone can point, click, hover, and visually track the page, the experience is fragile.

A few common problems:

• Focus is not visible, so you cannot tell where you are.
• Focus skips an important control.
• A custom dropdown opens with a mouse but not with the keyboard.
• A modal opens, but focus stays behind it.
• A menu can be opened but not closed.
• A date picker requires mouse selection.
• A “card” looks clickable but is not reachable as a link or button.

When you find a keyboard issue, document the exact path. “Keyboard does not work” is too broad. “The State dropdown on the Update address form receives focus, but pressing Enter, Space, or Arrow Down does not open the list” is much more useful.

Step 4: check links, buttons, and controls

Links and buttons should make sense by name and behavior.

A common issue is that a control makes sense visually but not structurally. A trash can icon may be obvious to a sighted mouse user in context. But if the button has no accessible name, someone using assistive technology may hear only “button.” A repeated “View” link may make sense in a table visually, but out of context it may not tell the user which record they are viewing.

Check for:

• Link text that makes sense out of context
• Buttons that describe the action
• Icon-only buttons with accessible names
• Repeated links that include enough context
• Controls that behave like the thing they visually imitate
• Disabled controls that explain what the user needs to do next

Some simple before-and-after examples:

• Instead of “Click here,” use “Download monthly statement.”
• Instead of an unlabeled trash icon, use an accessible name like “Delete mailing address.”
• Instead of repeated “View” links, use “View application 12345” or include the row context in the accessible name.
• Instead of “Read more,” use “Read more about renewal requirements.”

The point is not to make every label long. The point is to make the action clear.

For buttons, ask: what happens when I activate this?

For links, ask: where will this take me?

For custom controls, ask: does this behave like users expect? If something looks like a dropdown, it should work like a dropdown. If something looks like a button, it should be exposed and operated like a button.

Step 5: check forms, labels, instructions, and errors

Forms are one of the best places to learn accessibility review because the issues are common and the impact is easy to understand.

A form is not accessible just because the fields are visible. A user needs to know what each field is for, what format is expected, which fields are required, what went wrong, and how to fix it.

Check for:

• Every field has a visible label.
• Labels stay visible after someone starts typing.
• Required fields are identified clearly.
• Instructions and format requirements appear near the relevant field.
• Error messages are specific.
• Errors are connected to the fields they describe.
• Longer forms provide an error summary.
• The user can recover without guessing.

Placeholder text is a common trap. It can look like a label before someone starts typing, but it often disappears once the field has a value. That means the user may lose the field name while reviewing or correcting information. Placeholder text can be useful as an example or hint, but it should not be the only label.

Required fields are another common issue. A red asterisk may be visually familiar, but it is not enough by itself. The page should explain what the asterisk means, and the required state should be available programmatically.

Errors are where a lot of friction shows up.

Weak error:

Invalid input.

Better error:

Enter the date in MM/DD/YYYY format.

Weak error behavior:

The field has a red border, but there is no message.

Better error behavior:

The field has a visible message, the message explains how to fix the problem, and the message is associated with the field.

For longer forms, an error summary can help users understand what failed without hunting through the page. The summary should link or move focus to the fields that need attention.

Step 6: compare what you see with what assistive technology may receive

Some accessibility issues are visible. Others are hidden in how the page exposes information to browsers and assistive technology.

This is the part that can feel abstract at first.

A sighted mouse user may see:

• A magnifying glass icon
• A red error message under a field
• A modal on top of the page
• A custom dropdown that looks like a select field
• A large bold section title

But the exposed experience may be different:

• “Button, unlabeled”
• “Edit text, blank”
• Error message not announced with the field
• Dialog not identified
• Expanded or collapsed state not announced
• No heading in the page outline

The visible interface and the exposed interface need to tell the same story.

You do not need to become an expert in every assistive technology to understand this principle. For a first pass, you are trying to notice when the page depends only on visual cues.

Helpful questions:

• If I could not see the icon, would I know what the button does?
• If I navigated by form fields, would each field have a clear name?
• If I made an error, would the field tell me what went wrong?
• If a modal opened, would I know I was inside a dialog?
• If a dropdown expanded, would that state be communicated?

Tools can help here. Browser dev tools, accessibility tree inspectors, automated scanners, and screen readers can expose names, roles, states, and relationships. But the main habit is conceptual: do not assume that because something is visually obvious, it is available to everyone.

Step 7: check color, contrast, zoom, and reflow

Accessibility review is not only about screen readers and keyboards. People also need to be able to read, perceive, and use the screen when visual conditions change.

Check:

• Text contrast
• Icon and control contrast where needed
• Focus indicator contrast
• Text resizing
• Browser zoom at 200%
• Reflow at narrow widths
• Content that overlaps, clips, or disappears
• Instructions that rely only on color, shape, position, or icons

Color contrast is often easy to test with a tool. But do not stop at contrast alone. Look at whether the page still works when zoomed or narrowed.

At 200% zoom, can the user still complete the main task?

If the layout reflows to a narrow width, does content stay readable? Do buttons disappear? Do sticky headers cover fields? Does the page require horizontal scrolling in a way that makes the task difficult?

Also watch for instructions that only use color.

Problem example:

Fields in red are required.

Better:

Required fields are marked “Required.”

Color can support meaning, but it should not be the only way meaning is communicated.

Step 8: review dynamic content, modals, menus, and status messages

Web apps often change without loading a new page. That creates another set of accessibility issues.

Common patterns include:

• Modal dialogs
• Dropdown menus
• Accordions
• Tabs
• Toast notifications
• Loading spinners
• Search results that update dynamically
• Success and error messages
• Date pickers
• Autocomplete fields

These patterns can be accessible, but they need to manage focus, state, and announcements carefully.

For a modal dialog, check:

• Can it be opened with the keyboard?
• Does focus move into the dialog when it opens?
• Does the dialog have a clear name?
• Does focus stay inside while the dialog is open?
• Can it be closed with Escape or a clear close button?
• When it closes, does focus return to the button or control that opened it?

For menus and dropdowns, check:

• Can they be opened and closed with keyboard input?
• Is the expanded or collapsed state communicated?
• Does focus move predictably?
• Can the user select an option without a mouse?

For status messages, check:

• If something saves successfully, how does the user know?
• If results are loading, is that communicated?
• If a search returns no results, is the message clear?
• If an error appears, is it visible and discoverable?

A common issue is that the screen changes visually, but focus and announcements do not change with it. The app may look like it responded, but the user may not receive the same information.

Step 9: use tools carefully

Tools are useful. They are not the whole review.

Automated scanners can catch many detectable issues, such as missing form labels, missing button names, contrast failures, and some structural problems. Color contrast tools are helpful. Browser dev tools can expose names, roles, states, and relationships. Screen readers can help verify how information is announced when the reviewer knows how to use them responsibly.

Use tools as support, not as the definition of accessibility.

A tool may tell you that a button is missing an accessible name. That is useful. But it may not tell you whether the overall task flow makes sense. It may not know whether the instructions are clear. It may not understand whether the error message helps the user recover. It may not catch that focus order technically moves but feels confusing in practice.

A practical tool-supported first pass might include:

• Run an automated scan to catch common detectable issues.
• Check the keyboard path yourself.
• Inspect suspicious controls for name, role, and state.
• Use a contrast checker for text and key controls.
• Zoom and resize the page.
• Document the issue in terms of the user task, not only the tool result.

The tool output can be evidence. It should not be the whole finding.

Step 10: write findings that someone can act on

Finding an issue is only part of the work. The finding has to be clear enough for someone else to understand, reproduce, and fix.

A useful finding usually includes:

• Location or screen
• User action or steps to reproduce
• Actual result
• Expected result
• Why it matters
• Evidence, such as a screenshot, keyboard path, tool output, or screen reader note
• Suggested direction, if known
• Priority or impact note

Avoid findings like:

• “This page is not accessible.”
• “Fix keyboard issues.”
• “Labels are bad.”
• “Screen reader does not work.”

Those may be true in some general sense, but they do not give the team enough to act on.

A clearer pattern is:

On [screen], when [user action], [actual result]. This may affect [user/group/experience] because [impact]. Expected behavior: [expected result]. Evidence: [screenshot/tool output/keyboard steps].

Example:

On the Update mailing address screen, the State dropdown can be opened with a mouse but not with the keyboard. A keyboard user cannot complete the required address form without this field. Expected behavior: the control receives focus and can be opened and changed using keyboard input. Evidence: using Tab reaches the State field, but Enter, Space, and Arrow Down do not open the list.

Another example:

On the Date of birth field, the page shows an error after invalid input, but the error is not associated with the field. A screen reader user may not know what needs to be fixed when focus returns to the field. Expected behavior: the field announces or references the error message. Evidence: after submitting an invalid date and moving focus back to the field, the visible error is not announced with the field.

The goal is not to write a perfect legal record. The goal is to make the issue clear enough that a designer, developer, tester, or product owner can understand what happened and what needs attention.

Step 11: prioritize what to fix first

Not every issue has the same impact.

A first-time reviewer does not need a perfect severity model, but they should learn to separate polish from blockers and isolated issues from repeated patterns.

Ask:

• Does this block someone from completing the main task?
• Does this prevent keyboard or assistive technology use?
• Does this make error recovery unclear?
• Does this affect a repeated component or one isolated screen?
• Is this issue likely to appear in many places?
• Is this easier to fix now than later?

A low-contrast decorative icon may be worth cleaning up. But an unlabeled shared icon button used across the app may be more significant. A confusing error message on one optional field may matter. But an error pattern repeated across every required form may create much more friction.

A useful way to think about priority:

• Blocks the task and appears in a repeated pattern: fix first.
• Blocks the task on one screen: fix soon.
• Creates friction in a repeated pattern: address as a pattern, not one-off cleanup.
• Creates minor friction in an isolated place: document and schedule appropriately.

This is where accessibility connects to rework. If a problem comes from a shared component, design pattern, or requirement gap, fixing one screen may not be enough. The team should check where else the pattern appears.

Sample review packet: update mailing address

This example shows how a first review might look from start to finish.

Scenario:

A user needs to update their mailing address in a web app.

Screens reviewed:

• Account profile page
• Update mailing address form
• Confirmation modal
• Review changes page

User goal:

Update the mailing address and submit the change successfully.

Main path:

1. Open account profile.
2. Choose “Edit mailing address.”
3. Enter address fields.
4. Submit the form.
5. Review confirmation.
6. Save changes.

Likely error paths:

• Required field is left blank.
• ZIP code is entered in the wrong format.
• State dropdown is not selected.
• User opens the confirmation modal and needs to cancel or go back.

First-pass checklist used

• Identify the main user task.
• Walk through the task with a mouse.
• Walk through the task with keyboard only.
• Check page title, headings, and structure.
• Check links and buttons for clear names.
• Check form labels, instructions, required fields, and errors.
• Trigger errors and confirm the user can recover.
• Compare visible UI with names, roles, and states where possible.
• Check contrast, zoom, and reflow.
• Review modal behavior.
• Write findings with steps, actual result, expected result, and impact.

Notes from the walkthrough

Mouse path:

• The user can open the address form from the profile page.
• The form fields are visible.
• The submit button works with a mouse.
• The confirmation modal appears after submission.

Keyboard path:

• Focus reaches most text fields in order.
• Focus indicator is visible on text fields but weak on the “Edit mailing address” button.
• The State dropdown receives focus, but keyboard input does not open it.
• The confirmation modal opens, but focus stays on the page behind the modal.

Structure and labels:

• Page title is clear.
• Main heading is “Update mailing address.”
• Field labels are visible for Street, City, State, and ZIP code.
• The Address line 2 field uses placeholder text only and does not have a persistent visible label.

Errors:

• Required fields show red borders when empty.
• ZIP code error says “Invalid input,” which does not explain the expected format.
• Error messages appear visually, but at least one error is not associated with the field.

Zoom and reflow:

• At 200% zoom, the form is still readable.
• At narrow width, the submit button remains visible.
• The confirmation modal content is close to clipping at the bottom of the viewport.

What you see / what assistive technology may receive

Visible experience:

• A State dropdown appears after City.
• A red error message appears under ZIP code.
• A confirmation modal appears after Submit.

Possible exposed experience:

• State control does not behave like a standard select field.
• ZIP code field may not reference the visible error.
• Confirmation dialog may not be announced as a dialog.
• Focus may remain behind the modal.

Sample findings

Finding 1: State dropdown cannot be operated with keyboard

Location:

Update mailing address form, State field

Steps:

1. Open the Update mailing address form.
2. Use Tab to move focus to the State field.
3. Try Enter, Space, Arrow Down, and typing the state name.

Actual result:

The State dropdown receives focus, but keyboard input does not open the list or allow a selection.

Expected result:

A keyboard user can open the State dropdown, move through options, select a value, and continue through the form.

Impact:

A keyboard user cannot complete the required mailing address form without selecting a state.

Priority note:

High priority because it blocks the main task and may affect other forms if this dropdown is a shared component.

Suggested direction:

Use a native select where possible or ensure the custom control follows expected keyboard behavior and exposes name, role, value, and expanded/collapsed state.

Finding 2: ZIP code error message is not specific enough

Location:

Update mailing address form, ZIP code field

Steps:

1. Enter abc in the ZIP code field.
2. Submit the form.

Actual result:

The field shows the message “Invalid input.”

Expected result:

The error explains the expected format, such as “Enter a 5-digit ZIP code” or “Enter a ZIP code in 12345 or 12345-6789 format,” depending on what the system accepts.

Impact:

The user knows something is wrong but may not know how to fix it. This creates avoidable trial and error.

Priority note:

Medium to high priority, especially if vague error messages are used across the form or application.

Suggested direction:

Replace generic validation messages with field-specific messages that explain how to recover.

Finding 3: Confirmation modal does not move focus into the dialog

Location:

Confirmation modal after submitting the Update mailing address form

Steps:

1. Complete the address form.
2. Submit the form using the keyboard.
3. Continue pressing Tab after the modal appears.

Actual result:

The modal appears visually, but keyboard focus remains behind the modal and continues through the page content.

Expected result:

Focus moves into the modal when it opens, stays inside while the modal is open, and returns to the triggering control or a sensible next location when the modal closes.

Impact:

Keyboard and assistive technology users may not know the dialog opened or may interact with content behind it by mistake.

Priority note:

High priority because it affects confirmation and may affect every modal using the same component.

Suggested direction:

Follow an accessible dialog pattern: move focus into the dialog, give it a clear name, keep focus inside while open, support Escape or a clear close action, and return focus when closed.

What the team should check next

After finding these issues on the address flow, the team should check related patterns:

• Are the same dropdowns used on other forms?
• Do other modals have the same focus behavior?
• Are error messages vague across the app?
• Are any fields using placeholder-only labels?
• Are repeated components documented in the design system or component library?

This is where a first review becomes more useful than a single-screen checklist. The team is not only fixing one issue. They are learning where the product may repeat the same issue.

Quick checklist for a first review

Use this as a practical reference while reviewing.

• Identify the main user task.
• Walk through the task like a user would.
• Check page title, headings, and structure.
• Complete the task with keyboard only.
• Confirm focus is visible and logical.
• Check links and buttons for clear names.
• Check forms for labels, instructions, required fields, and errors.
• Trigger errors and confirm the user can recover.
• Compare visible UI with names, roles, states, and relationships where possible.
• Check contrast, zoom, and reflow.
• Review modals, menus, dynamic updates, and status messages.
• Use tools as support, not as the whole review.
• Write findings with steps, actual result, expected result, and impact.
• Prioritize blockers and repeated patterns first.

Common mistakes to avoid

A few patterns create trouble during first reviews.

Starting with a tool scan and stopping there

A scan can help, but it does not understand the whole task. Use it as one input.

Reviewing isolated elements without understanding the user goal

A page is not just a collection of controls. The user is trying to complete something.

Only checking the mouse experience

If the review depends on pointing, clicking, and hover behavior, it will miss common barriers.

Treating visual cues as enough

Icons, colors, red borders, layout, and bold text may not communicate the same information programmatically.

Writing findings too vaguely

A vague finding creates more work for the person who has to fix it. Specific steps and expected behavior reduce back-and-forth.

Missing repeated patterns

If a problem comes from a shared component, fixing one screen may leave the real issue in place.

Treating a first pass as final approval

A first review helps catch common issues. It does not prove the product is fully accessible.

Questions to keep beside you during review

If you only remember a few questions, use these:

• What is the user trying to do here?
• Can the task be completed without a mouse?
• If something goes wrong, can the user tell what happened and how to fix it?
• Do links and buttons make sense without relying only on visual context?
• Does the visible structure match the underlying structure?
• Are repeated components creating repeated problems?
• Is this issue likely to become more expensive if we wait?
• What evidence would help someone fix this without guessing?

A simple issue-writing template

Use this when documenting findings:

On [screen or component], when [user action], [actual result]. This may affect [user/group/experience] because [impact]. Expected behavior: [expected result]. Evidence: [screenshot, keyboard steps, tool output, or screen reader note]. Priority: [blocker/high/medium/low or short impact note].

Example:

On the Update mailing address screen, the State dropdown can be opened with a mouse but not with the keyboard. A keyboard user cannot complete the required address form without this field. Expected behavior: the control receives focus and can be opened and changed using keyboard input. Evidence: using Tab reaches the State field, but Enter, Space, and Arrow Down do not open the list. Priority: high, because this blocks the main task and may affect other forms using the same component.

Where to go deeper

Use this guide as the first path, then follow the deeper Field Guide pages for the issue you found.

Field Guide pages to keep close:

• Intake Accessibility Questions for questions to ask before the screen is built.
• Accessibility Requirements Checklist for turning those questions into acceptance criteria.
• Review Readiness and Review Readiness Checklist for deciding whether a screen is ready to send forward.
• Forms and Labels, Error Messages and Recovery, and Form Review Checklist for form-heavy screens.
• Keyboard-Only Navigation, Focus Visible and Focus Order, and QA Keyboard Check for no-mouse review.
• Vendor and Third-Party Accessibility Field Guide and Vendor Accessibility Questions Checklist when part of the app is vendor-hosted, embedded, or configurable.

External references can help too:

• W3C WAI Accessibility Perspectives Videos: useful for connecting accessibility to everyday user impact.
• W3C Before and After Demonstration: useful for seeing inaccessible and improved versions of the same site.
• W3C Easy Checks: useful as a companion for first-pass checks.
• WCAG Quick Reference: useful when you need to connect findings back to the standard.
• ARIA Authoring Practices Guide: useful for patterns like dialogs, accordions, menus, tabs, and custom controls.
• WebAIM Contrast Checker: useful for checking color contrast.
• WebAIM Forms tutorial: useful for labels, instructions, and errors.
• The A11Y Project Checklist: useful as a plain-language supplemental checklist.

Closing thought

The point of a first accessibility review is not to make one person responsible for catching everything.

The point is to make common issues visible earlier.

When a team can look at an ordinary web app screen and notice unclear labels, missing keyboard support, vague errors, weak focus, broken modal behavior, or confusing structure, the work changes. Accessibility stops being something that only appears at the end. It becomes part of how the team understands quality while the product is still being shaped.

That does not remove the need for deeper review. It makes deeper review more useful.

The team shows up with fewer surprises, clearer questions, and a better understanding of the patterns they need to fix.

What to do next

• Write down the task you reviewed, the path you took, and the issues that would block someone from completing it.
• Turn clear issues into tickets with expected behavior, evidence, and ownership.
• If the screen includes forms or errors, use Form Review Checklist and Error Messages and Recovery.
• Before sending the work to formal review, use the Review Readiness Checklist.