ARIA labels and landmarks give screen readers additional context that visual design alone conveys to sighted visitors — identifying a search box as a search box, marking navigation regions, describing an icon-only button’s actual function — implemented where your site’s existing markup genuinely needs the extra clarity.
ARIA label & landmark implementation
ARIA labels and landmarks added only where your existing markup genuinely needs the extra context.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Access to the site’s templates and components needing ARIA implementation
- Confirmation of any specific components you already know are unclear to screen reader users
- Confirmation this is being added to existing functionality, not requesting new features
This or something else?
| Screen reader users can’t tell what specific elements or regions on your page actually are or do | This fix covers it |
| You want a broader accessibility audit first, to identify where ARIA is actually needed | Accessibility audit report – WCAG 2.2 AA |
| You want screen reader issues fixed more broadly, not just ARIA labels and landmarks specifically | Screen reader compatibility fixes, the broader version |
| Your headings or semantic HTML structure itself needs correcting, not ARIA labels added on top | Heading hierarchy correction, or Semantic HTML remediation for extractability |
What we do
- Identify elements and regions lacking sufficient context for screen reader users
- Implement appropriate ARIA labels for icon-only buttons and ambiguous controls
- Add landmark roles marking major page regions (navigation, main content, search)
- Verify implementation doesn’t duplicate or conflict with already-correct semantic HTML
- Test using an actual screen reader to confirm the added context is genuinely helpful
- Check across a representative sample of affected page types
What is included
- ARIA labels implemented for ambiguous or icon-only elements
- Landmark roles added for major page regions
- Verified no conflict with existing correct semantic markup
- Testing using an actual screen reader
Not included
- Broader screen reader compatibility issues beyond labels and landmarks specifically, a separate, related fix
- Correcting underlying semantic HTML structure, a separate, related fix if that’s the more fundamental issue
- Building new functionality — this adds clarity to what already exists
- Ongoing implementation as new components are added
Questions about this fix
Doesn't semantic HTML already handle this without needing ARIA?
Ideally yes, for most cases — correct semantic HTML (a real button element, a nav tag) is usually the better first choice, and ARIA is meant to supplement gaps semantic HTML can't fill on its own, like clarifying what a decorative icon-only button actually does.
Can adding ARIA labels incorrectly make things worse?
Yes, genuinely — a wrong or redundant ARIA label can confuse a screen reader user more than having none, which is exactly why we test with an actual screen reader rather than just adding labels and assuming they help.
How do you know which elements actually need this?
We look for ambiguous elements — icon-only buttons, custom components without semantic meaning, or regions a screen reader user couldn't otherwise identify — rather than adding ARIA indiscriminately to everything.
Will this change how my site looks?
No, ARIA attributes and landmark roles are invisible to sighted visitors and don't affect visual design — they specifically provide additional information to assistive technology.
Is this enough on its own to make my site accessible?
No single fix achieves full accessibility on its own — this addresses a specific, real gap, but a comprehensive audit is the way to understand your site's full accessibility picture.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.