Accessibility Fixes as a GitHub Pull Request

A pull request is the safest way for an accessibility fix to reach a live site, because nothing lands without a human looking at it first. The flow has four steps: scan the code, propose the fix as a diff, review the diff, and merge it. Each step leaves a record. A developer who has reviewed pull requests for any other kind of fix already knows this flow. Accessibility fixes fit it well, because most of them are small, visible changes to markup: a label added, a name given to a button, a heading order corrected.

Step one: scan the code

The scan runs against the source code, not against a screenshot of the page. Axeazy's scan runs 98 automated checks against WCAG 2.2 AA, grouped into 14 categories, from alt text and form labels to heading structure and landmark structure. The scan uses axe-core, the same open source engine behind the accessibility panel in Chrome DevTools, and the method is described on Axeazy's methodology page. A scan result names the page, the problem, and the code location, so a developer can open the file and see the exact lines. That precision is what separates a code fix workflow from a report that only counts problems.

Step two: the fix arrives as a diff

For sites with a GitHub repository, Axeazy sends fixes as a real pull request with a visible code diff that the owner or developer reviews and merges. Nothing is applied without review. A diff shows old lines and new lines side by side, so the reviewer sees exactly what changes. Here is a short example diff, written as an example, not taken from a real site:

• Old line: a button element with no text and no name, shown only as an icon.
• New line: the same button element with an accessible name added, describing what the button does.

That is the whole change for one common finding: a button that a sighted visitor understands from its icon, and a screen reader visitor hears as nothing. A diff like this is easy to review, easy to test, and easy to revert if it breaks a layout. Larger findings produce larger diffs: a heading order corrected across a template, a form field given a label tied to its input, a landmark structure added to a page shell. Each one is still a diff a developer can read line by line.

Step three: review before merging

Review an accessibility pull request the same way as any other pull request, with three extra checks. First, read the diff for side effects: does a heading change alter the visual layout, does a label change alter a form's spacing, does a landmark change move content a screen reader announces? Second, test the changed pages with a keyboard only: tab through the form, open the menu, submit the path, and confirm focus never disappears. Third, run the scan again on the changed branch and confirm the finding is gone without new findings appearing beside it. Colour contrast and landmark restructuring need owner approval as well, because they move visible design: Axeazy detects contrast problems and calculates a correct colour, but a visible colour change is never applied without owner approval, and landmark restructuring and heading order changes also need owner approval because they move existing tags.

A reviewer who is not an accessibility specialist can still review well by asking three questions: what was wrong, what changed, and how was it tested? A pull request that answers all three in its description is ready to merge. A pull request that answers none of them should go back, however clean its diff looks.

Step four: merge, rescan, and keep the record

After merging, the next scan should show the finding gone, and the dated record should show the scan, the fix, and the rescan with their dates. Axeazy records every scan and fix with a date and time, and reports can be exported as a PDF. Weekly monitoring on paid plans catches new problems after later updates, so a merged fix that regresses in a future release appears in the next report with a date. That loop, scan, diff, review, merge, rescan, is the whole workflow. It is slower than pasting a script, and it lasts longer, because the fix sits in the code through the next page load, the next theme update that does not overwrite it, and the next scan.

When a pull request is not the right path

A pull request fits sites with a repo and a developer who can review. WordPress sites without a repo use a different path: Axeazy's free plugin applies three render-time fixes, and paid plans add weekly scans and further fixes. Shopify stores and other sites with no repo get a scan plus a guided checklist with computed fix values to apply by hand, not automatic template changes. A team with no developer should not force a pull request workflow. It should use the checklist path, and ask a developer for help with the items that touch templates. The goal is the same in every path: a fix in the code, checked by a person, recorded with a date.

Related reading

For the developer tool list behind this workflow, read best accessibility testing tools for developers, and for the React and Next.js version, read best accessibility tools for React and Next.js. For the buyer checklist, read accessibility tool buyer checklist.

• For badges compared, read accessibility badge for your website, compared.

FAQ

Does a pull request fix everything a scan finds?

No. A pull request fixes code findings: labels, names, heading order, landmark structure, tab order, and similar markup items. Contrast changes need owner approval, complex widgets need a person to design the interaction, and documents such as PDFs need a separate plan, because Axeazy does not scan PDFs.

Who should review an accessibility pull request?

The site owner or their developer, the same person who reviews any other change to the site. A reviewer does not need to be an accessibility specialist to check what changed and how it was tested, but a specialist review is worth adding when a template or a checkout path changes.

What if a fix breaks the layout?

Revert the pull request, because a diff is easy to revert, and fix the layout problem in a new pull request. That safety is the point of the workflow: a fix that can be reviewed can also be undone, while a change made straight to a live site cannot.

Last checked: October 31, 2026 Sources: W3C WCAG 2.2; Axeazy capabilities, methodology, and pricing pages.

Compare the plans on Axeazy's pricing page, then open one pull request diff and read it line by line before you merge your first accessibility fix.