ARIA labels / roles

ARIA markup is adding accessibility attributes (roles, aria-label/aria-labelledby labels, aria-expanded/aria-checked states, etc.) to elements that lack built-in HTML semantics: custom menus, tabs, accordions, sliders, modals, dynamic regions. This lets screen readers correctly announce what an element is, what it is called and what state it is in. Honestly about the main principle, this is key: the first rule of ARIA is 'don't use ARIA if native HTML solves the task'. An ordinary `<button>` is accessible by itself; ARIA is needed where there is no built-in semantics. Honestly about the risk: INCORRECT ARIA is worse than none — a wrong role or an unsynchronized state breaks voicing and confuses the user more than a 'bare' element. So this is work for a careful hand and testing, not 'slapping on attributes'. Honestly about the boundary: ARIA is a targeted tool, it does NOT make the site accessible by itself and does not replace proper semantics, keyboard accessibility (806) and screen-reader testing (805) — it works in combination. Honestly about the process: when components change, ARIA must be maintained (state desync is a common bug). Honestly about the effect: correct ARIA makes complex widgets clear to assistive technologies; we do not guarantee direct sales growth. Honestly about access: access to the code/templates is needed. An important boundary: this is ARIA; screen-reader adaptation in general is 805, keyboard is 806. Picture this: instead of 'the screen reader does not understand what this custom element is' — it correctly announces the role, name and state. The base price starts from 18,000 ₽ (depends on the number of components).

• The screen reader does not understand custom widgets — they are 'mute'.
• States (open/selected) are not announced to assistive technologies.
• ARIA is added incorrectly and breaks voicing.
• Custom menus/tabs/sliders are inaccessible to blind users.

• An audit of where ARIA is really needed (and where native HTML is enough)
• Correct roles, labels (aria-label/labelledby)
• Correct states (aria-expanded/checked/selected, etc.)
• Synchronizing states with real behavior
• Testing with a screen reader (that things are announced correctly)
• Indicating boundaries (ARIA — targeted, not a replacement for semantics)
• A link with keyboard (806) and screen readers (805)
• Handover and review with you

• Complex widgets are clear to assistive technologies
• Roles, names and states are announced correctly
• ARIA applied targetedly and correctly (without harm)
• Accessible custom components (combined with 805/806)

• We determine where ARIA is needed and where HTML is enough; collect access
• We add correct roles/labels/states, synchronize
• We test with a screen reader, give a maintenance plan, review with you

• Let's just add ARIA everywhere for reliability?

  No, that is harmful. The first rule of ARIA is not to use it where native HTML is enough, and incorrect ARIA is WORSE than none: a wrong role or an unsynchronized state breaks voicing and confuses the user. We apply ARIA targetedly and with testing, not 'just in case everywhere'.

• Will ARIA make the site accessible?

  By itself — no. ARIA is a targeted tool for complex widgets, but it does not replace proper semantics, keyboard accessibility (806) and screen-reader testing (805). Accessibility is a combination of layers. We will honestly advise what is needed as a whole, not pass off ARIA as the entire solution.

• Does this need maintenance?

  Yes. When components change, ARIA states are easy to desync from real behavior (a common bug: visually open, but aria-expanded=false). Accessibility is a process: we will give recommendations so new and changed components are marked up correctly from the start.