Keyboard navigation

Keyboard navigation is bringing the site to full keyboard operability: all interactive elements (links, buttons, fields, menus, tabs, accordions, sliders, modals) are reachable and work via Tab/Shift+Tab/Enter/Space/arrows, in a logical and predictable order, without 'traps' (which you cannot leave with keys) and without invisible focus. Honestly about dependency on components, this matters: standard elements are made accessible relatively easily, while complex custom widgets are harder, and some third-party ready-made components do not support the keyboard at all by default. We honestly mark such places and solve them: rework or replace with an accessible alternative; the behavior of someone else's ready-made widget 'as is' cannot be guaranteed. Honestly about the combination: keyboard accessibility is closely related to focus management (807) and screen-reader accessibility (805) — often done together. Honestly about the process: when new interactivity is added, keyboard accessibility must be maintained, otherwise unreachable elements appear again. Honestly about the effect: critical for people with motor impairments and screen-reader users; this is about accessibility, we do not guarantee direct sales growth. Honestly about access: access to the code/templates is needed. An important boundary: this is keyboard navigation; focus visibility and order in detail are 807, screen readers are 805. Picture this: instead of 'you cannot traverse the site without a mouse, elements are unreachable' — everything works from the keyboard in a logical order. The base price starts from 18,000 ₽ (depends on the number of interactive components).

• You cannot traverse the site without a mouse — some elements are unreachable.
• Focus gets 'stuck' in a trap or disappears from view.
• The Tab order is chaotic and illogical.
• Third-party widgets do not work from the keyboard.

• Reachability of all interactive elements from the keyboard
• A logical and predictable navigation order (Tab/Shift+Tab)
• Eliminating focus 'traps'
• Accessibility of custom widgets (menus, tabs, sliders, modals)
• Marking/reworking/replacing third-party inaccessible components
• Indicating boundaries (others' widgets; maintenance on changes)
• A link with focus management (807) and screen readers (805)
• Handover and review with you

• The site is operable by keyboard wherever technically feasible (except unsupported third-party components)
• A logical navigation order without traps
• Custom and (where possible) third-party widgets are accessible
• A critical access base (for motor impairments and screen readers)

• We traverse the site by keyboard, record inaccessible places; collect access
• We make elements reachable, fix order and traps, rework widgets
• We re-check, mark what to replace, give a maintenance plan, review with you

• Will all widgets work from the keyboard?

  We make standard and custom elements accessible. But honestly: some third-party ready-made widgets do not support the keyboard at all by default — they will have to be reworked or replaced with an accessible alternative, and the behavior of someone else's component 'as is' cannot be guaranteed. We will mark such places and solve them, not passing off wishes as done.

• Is this the same as focus management?

  Related, but not the same. Keyboard navigation is about everything being reachable and working from keys. Focus management (807) is about focus visibility, its order, return and trapping (e.g. in modals). We often do them together; we will honestly say whether you need both.

• Done once — and that's it?

  Basically yes, but when new interactivity is added, keyboard accessibility is easy to break (an unreachable element, a new trap). Accessibility is a process: checking on changes is needed. We will give recommendations so new components are made accessible right away.