Modal accessibility

Modal accessibility is bringing popups and dialogs to accessible behavior: a correct role (dialog) and associated title/description for the screen reader, keeping focus inside the window while it is open (focus trap), moving focus into the window on opening and announcing it to the screen reader, closing by Esc and by button, RETURNING focus to the original element after closing, an 'inert' background (you cannot accidentally click/tab through it under the window). Honestly about the combination, this matters: an accessible modal relies on focus management (807) and correct ARIA (808) — related things, often done as a set. This service applies them to a specific component type — modal windows. Honestly about third-party modals: if your popups are on a ready-made third-party plugin, its accessibility may be incomplete — it will have to be reworked or replaced with an accessible solution; the behavior of someone else's ready-made widget 'as is' cannot be guaranteed, we will honestly mark such places. Honestly about coverage: accessible modals are an important area (popups often break accessibility), but not all of site accessibility. Honestly about the process: new popups must be made accessible right away — otherwise the problem returns. Honestly about the effect: keyboard/screen-reader users do not get stuck in popups; we do not guarantee direct sales growth. Honestly about access: access to the code is needed. An important boundary: this is modals; general focus management is 807, ARIA is 808, keyboard is 806. Picture this: instead of 'a popup opened, but focus stayed on the background, you cannot leave with keys' — a correct accessible dialog. The base price starts from 15,000 ₽ (depends on the number and complexity of modals).

• A popup opened, but focus stayed on the background — you cannot leave with keys.
• The screen reader does not announce the window opening — a blind person did not understand.
• Esc does not close, focus does not return to place.
• The background under the window is clickable/tabbable through.

• A correct dialog role and associated title/description
• Keeping focus in the window (focus trap)
• Moving focus into the window and announcing to the screen reader
• Closing by Esc and button, returning focus after closing
• An 'inert' background under the open window
• Reworking/replacing inaccessible third-party modals
• Indicating boundaries (relies on 807/808; others' widgets)
• Handover and review with you

• Focus is kept in the window and returns to place
• The screen reader announces the dialog opening
• Esc and button close it, the background does not interfere
• Accessible modals (combined with 807/808)

• We find modals and check their behavior from keyboard/screen reader; collect access
• We set up the role, focus trap, announcements, Esc, return, inert background
• We rework/replace inaccessible widgets, review with you

• How does this differ from focus management?

  Focus management (807) is the general focus mechanics across the site. This service applies it (plus ARIA 808) specifically to modal windows: dialog role, focus trap, announcement, Esc, return, inert background. We often do them as a set; we will honestly say whether you need modals separately or more broadly.

• Our popups are on a ready-made plugin — will it work?

  It depends on the plugin. Some third-party modals are incompletely accessible (no focus trap, not announced, background clickable). Where possible we rework, where not we will propose replacing with an accessible solution. The behavior of someone else's ready-made widget 'as is' honestly cannot be guaranteed; we will mark such places.

• Is this a one-off job?

  Basically yes, but new popups must be made accessible right away, otherwise the problem returns (a new inaccessible dialog = a new trap). We will give recommendations so future modals are built accessibly from the start. Accessibility is a process, not a one-off point.