In our observations, the low-vision segment is not a «narrow group» but a broad spectrum: from users with color blindness and presbyopia to people temporarily working in low-light conditions. They more often increase font sizes, use screen magnifiers and prefer clear, high-contrast interfaces with predictable navigation. On e‑commerce and fintech sites this segment shows a high intent to purchase if the interface is accessible and the steps are clear.

Business‑benefits consist of three streams: additional reach (organic + paid traffic converts better), reputational effect (especially in competitive markets like banks and pharmacy chains) and the technical synergy «SEO and accessibility». Semantic markup, alt‑texts, correct headings and landmarks help search crawlers.

In the case of one pharma e‑commerce where we fixed contrast, focus, alt and keyboard navigation, drop-offs decreased by 12%, and conversion from the product card increased by 9.3% with the same advertising budget.

Legal risk and compliance are also important. European directives (EN 301 549, WAD), the ADA and the WCAG 2.1/2.2 standard: benchmarks that Ukrainian companies are already gravitating toward, especially those with exports or branches in the EU. A public accessibility statement increases trust and disciplines internal processes: you record the level of conformance (A/AA), a roadmap and a contact for feedback.

The project’s economics are simple: CAPEX – one-time improvements (audit, remediation, pattern implementation), OPEX – maintenance (regression tests, monitoring, training). ROI is composed of reduced traffic leakage (growth in task completion and conversion rate), reduced risk of legal claims and increased LTV through retention. In BUSINESS SITE projects we calculate ROMI over a 3–6 month horizon, and in e‑commerce we often see payback within 2–3 sprints.

BUSINESS SITE practice confirms: quick wins deliver contrast, visible focus, alt‑texts, correct labels and skip links. These tasks take weeks, not months, and immediately affect user behavior.

Checklist (business block)

chek list biznes blok h2 img 1 Adapting a website for visually impaired users

  • Determine the market: share of mobile traffic, share of users who increase font size (based on CSS prefers-reduced-motion and zoom events).
  • Set the goal: increase conversion by X%, reduce bounce rate by Y%.
  • Assign owners: product, design, development, QA, marketing.
  • Adopt the compliance standard: WCAG 2.2 AA as the target.
  • Prepare an accessibility statement (level, date, roadmap).

Code examples/snippets

primery koda snippety h2 img 2 Adapting a website for visually impaired users

Accessibility statement section in the footer:

Tools/resources

instrumenty resursy h2 img 3 Adapting a website for visually impaired users

Product ticket template

shablon product ticket h2 img 4 Adapting a website for visually impaired users

  • Title: Low CTA contrast on mobile
  • Problem: The ‘Buy’ button contrast is 2.8:1, below 4.5:1.
  • Steps: Open the product card → check the contrast in DevTools.
  • Severity: High (affects payment).
  • Priority: P1
  • Acceptance criteria: contrast ≥ 4.5:1 in all states, verified with WAVE/axe.

WCAG: requirements for visually impaired users

wcag trebovaniia dlia slabovidiashchikh h2 img 5 Adapting a website for visually impaired users

WCAG 2.1 and 2.2, a set of testable criteria (Success Criteria, SC) at levels A/AA/AAA. For commercial sites it’s reasonable to aim for level AA: it provides an accessible interface without excessive costs. Level AAA is useful for specific scenarios, but as a general standard it is too costly.

Critical for visually impaired users: contrast (SC 1.4.3/1.4.11), text scalability (SC 1.4.4), visible focus (SC 2.4.7), keyboard accessibility (SC 2.1.1/2.1.2), recognizable form labels (SC 3.3.2) and no dependence on color alone (SC 1.4.1). Implement these SCs first: they have the greatest effect on task completion.

A practical approach to documentation: record SC coverage in a table where each criterion has a status, an owner and a date of review. In my experience, such a registry simplifies reporting to management and builds a transparent roadmap.

Checklist (level AA)

  • 1.4.3 Text contrast ≥ 4.5:1; large text ≥ 3:1.
  • 2.1.1 Full keyboard navigation; focus is visible.
  • 2.4.1 Skip links; correct landmarks.
  • 3.3.1/3.3.3 Clear form errors and hints.
  • 1.4.4 Text can be enlarged to 200% without loss of content.

Code/snippet

Skip link to the start of content:



...



.skip-link { position:absolute; left:-9999px; }
.skip-link:focus { left:16px; top:16px; background:#fff; padding:8px; }

Tools/resources

Product ticket template

  • Title: Add a skip link and landmarks
  • Problem: The user cannot quickly jump to the content.
  • Steps: Open the homepage, press Tab, there is no visible ‘Skip’.
  • Severity: Medium
  • Priority: P2
  • Acceptance criteria: Works in NVDA/VoiceOver, covered by SC 2.4.1.

Inclusive web design: contrast

Contrast is fundamental. For regular text use a minimum of 4.5:1, for large text (≥18pt or 14pt bold), 3:1. Include color contrast checkers at the design stage and implement palettes in the design system to avoid situational errors.

Font scaling and responsive typography improve readability. Use rem/em, limit line length to ~60–80 characters, set line-height to 1.4–1.6. In one online appliance store where we implemented responsive typography and increased contrast, task time for finding a product decreased by 18% on mobile.

Consider color blindness: check palettes for deuteranopia, protanopia, tritanopia. In interfaces with financial transactions (online banking) we additionally added icons and textual cues so emphasis did not rely solely on color.

Text and background contrast

Measure and record contrast directly in layouts. The Stark plugin helps in Figma; in the browser, use DevTools and the axe extension. Save the set of approved color tokens in the design system and automate checks during the build.

Code/snippet (prefers-reduced-motion):

@media (prefers-reduced-motion: reduce) {
  * { animation-duration: 0.01ms; animation-iteration-count: 1; transition:none; }
}

Checklist

  • Check contrast of all button/link states.
  • Limit line length, adjust line-height.
  • Use rem/em for font scaling.
  • Emulate color blindness (Stark/Sim Daltonism).
  • Enable prefers-reduced-motion for animations.

Tools

Product ticket template

  • Title: Insufficient contrast of secondary links
  • Issue: The color #8ea4c8 on white gives ~2.7:1.
  • Steps: Check via CCA on the product card.
  • Severity: High
  • Priority: P1
  • Acceptance criteria: Contrast ≥ 4.5:1, design-system tokens updated.

Typography for low-vision users

Recommendations: base font size at least 16px, on desktop 18–20px for main text in B2C scenarios; line-height 1.5; leading and letter-spacing: for headings, apply carefully, avoid ‘squashing’. Font scaling up to 200% should not break the grid or important CTAs.

Code/snippet (responsive typography):

html { font-size: 100%; }
body { font-size: 1rem; line-height: 1.5; }
h1 { font-size: clamp(1.8rem, 2.5vw, 2.4rem); }

ARIA and semantic HTML for accessibility

I always recommend: semantic HTML first, then ARIA. Native elements: buttons, links, form fields, already contain the correct roles and behavior. If a custom component is needed, add ARIA roles cautiously and only when necessary.

For dynamic content use ARIA live regions (aria-live=”polite”/”assertive”) and appropriate roles: alert, status, dialog. In a travel service project we improved booking status notifications via aria-live and reduced the number of chat inquiries by 14%; people began to hear what had previously been “silent”.

Semantic landmarks (header, nav, main, footer) and headings h1–h6 create a logical structure for screen readers NVDA, JAWS, VoiceOver and TalkBack. This speeds up navigation and reduces time on task.

Code/snippet (live region):

Checklist

  • Check where native elements have been replaced by div/span → restore native elements.
  • For dynamic content, add aria-live and describe the behavior.
  • Add landmarks and correct headings.
  • Document ARIA in the component library.

Tools

Product ticket template

  • Title: Add aria-live for “product in cart” notifications
  • Issue: Screen reader is silent when adding a product.
  • Steps: NVDA + Firefox, “Add to cart” → no announcement.
  • Severity: Medium
  • Priority: P2
  • Acceptance criteria: The message is read by NVDA/JAWS/VoiceOver.

ARIA errors and antipatterns

Common mistakes: using role=”button” on a div without keyboard behavior; hiding focus; aria-hidden on active elements; excessive use of aria-* where native is sufficient. It’s recommended to replace role=”button” with

Navigation, focus, keyboard accessibility

Keyboard navigation is mandatory: Tab order is logical, focus is visible and high-contrast, interactive elements are accessible via Enter/Space. Add skip links and manage focus in modals and SPA scenarios so the user doesn’t lose context.

The focus state is part of the brand. Set a clear border or highlight with contrast against the background ≥ 3:1. In an online banking project we implemented an animated but “calm” focus indicator and saw an increase in successful logins among TalkBack users.

Check compatibility with screen magnifiers and zoom tools: windows should scale, tooltips should not cover fields, tables should have a fixed tab order and headers.

Code/snippet (visible focus):

:focus { outline: 2px solid #0a84ff; outline-offset: 2px; }

Checklist

  • Full keyboard navigation, without focus traps.
  • Visible focus on all interactive elements.
  • Focus management when opening and closing modals.
  • Skip links, logical Tab order.
  • Test in NVDA/VoiceOver, check with a screen magnifier.

Tools

Product ticket template

  • Title: Add focus management in the payment modal
  • Problem: The focus falls behind the overlay, making it difficult to complete payment with the keyboard.
  • Steps: Open the modal, press Tab → focus jumps outside the modal.
  • Severity: High
  • Priority: P1
  • Acceptance criteria: Focus is trapped on open and returns to the trigger on close.

Buttons and navigation for people with low vision

Design clickable areas 44×44px and larger, use clear labels and explicit hover/active states. Links should look like links, buttons like buttons; mixing styles makes perception more difficult.

Code/snippet:

button, .btn, a.btn { min-width: 44px; min-height: 44px; }
a { text-decoration: underline; }
a:hover { text-decoration-thickness: 2px; }

alt, audio description and subtitles

Alt‑text should convey the purpose of the image in context. Decorative images get an empty alt=””. Informational graphics and SVGs, with roles and descriptions; complex diagrams – with an expanded textual description nearby or via a link.

Video and audio: with subtitles and transcripts. In videos about delivery (Nova Poshta) and payments (PrivatBank/Monobank) we added subtitles and a short audio description of important graphics, which improved understanding of the steps and reduced support requests.

Correct alt‑attributes help search: product images with relevant captions improve visibility in image search and product cards.

Code/snippet (accessible SVG):


  Delivery icon
  Truck next to a clock

Checklist

  • Alt text by purpose: informative, short, without ‘image’.
  • Empty alt for decorative images.
  • Long descriptions for complex charts.
  • Captions/transcripts for video/audio.
  • Check speech output in NVDA/JAWS.

Tools

Product ticket template

  • Title: Add subtitles to the video «Payment and delivery»
  • Problem: No subtitles, loss of context.
  • Steps: Open the video, mute the sound → information unavailable.
  • Severity: Medium
  • Priority: P2
  • Acceptance criteria: Subtitles and transcript published, verified for synchronization.

Alternative text for images

Correct: alt=”Wrist blood pressure monitor, model X200, 15% off”. Incorrect: alt=”product photo”. If the image is a button or link, the alt/aria-label should describe the action: alt=”Add X200 blood pressure monitor to cart”. For product collections, use a single alt template to improve consistency.

Forms and validation for the visually impaired

Each field: with a label linked via for/id, or with an aria-label if the label is visually hidden. Describe form errors as text, link them via aria-describedby, announce them via a live region. Provide input format guidance in advance, not afterwards.

We recommend replacing CAPTCHA with invisible methods: behavioral signals, honeypot fields, risk scoring. In a pharma company project we removed the visual CAPTCHA, reduced abandoned forms by 21% and maintained the same level of protection.
Code/snippet (accessible form):




We will send a receipt

Checklist

  • Labels and hints associated with fields are present everywhere.
  • Errors are announced to screen readers and clearly highlighted.
  • Focus moves to the first error.
  • An alternative to CAPTCHA without visual tasks.
  • Dates/phones: input masks with format hints.

Tools

Product ticket template

  • Title: Accessible registration form validation
  • Problem: Errors are not announced, aria-describedby attributes are missing.
  • Steps: Leave the field empty → submit → the screen reader is silent.
  • Severity: High
  • Priority: P1
  • Acceptance criteria: Errors are visible/announced, focus moves to the first error.

Accessibility testing tools

Automated tools catch up to 30–40% of issues. axe‑core, Google Lighthouse, WAVE, Pa11y and Tenon.io detect obvious violations: contrast, missing alt attributes, incorrect roles. Manual auditing covers scenarios: navigation logic, focus management, expected ARIA behavior.

I recommend combining a heuristic checklist, automated checks and manual testing with NVDA/VoiceOver. In e‑commerce projects BUSINESS SITE we run Pa11y in CI, and for regressions: axe‑core on key pages: product page, cart, checkout.

Audit checklist

  • Run Lighthouse Accessibility ≥ 90.
  • WAVE/axe without critical errors.
  • Manual keyboard check (no mouse).
  • NVDA/VoiceOver: check important scenarios.
  • Report as remediation tickets.
Code/snippet (Pa11y CI skeleton):

pa11y https://example.com --threshold 0 --reporter json > pa11y.json

Tools

Product ticket template

  • Title: Fix axe errors on the cart page
  • Issue: 6 violations (contrast, aria-roles).
  • Steps: Run axe → save the report.
  • Severity: High
  • Priority: P1
  • Acceptance criteria: 0 critical errors, 0 major warnings.

Choosing accessibility audit tools

Consider CI integration, SC coverage, reporting convenience and support. For multisite setups a headless‑mode and export to JSON/HTML are useful. axe‑core CLI and Pa11y are well suited for pipelines, WAVE, for quick manual checks, Lighthouse – for an overall assessment.

Low-vision testing

Recruit participants ethically: compensate for time, provide clear instructions, and offer support during tests. Look for users with color blindness, low visual acuity, and those who use screen readers NVDA/JAWS, VoiceOver, or TalkBack.

Testing scenarios: use real tasks: find a product, place an order with Nova Poshta, pay with a PrivatBank/Monobank card, find a branch address. Measure task completion, time on task, errors, and subjective NPS. On one news portal, after a series of sessions we redesigned the navigation and reduced time on task for the target article by 25%.

Analyze recordings, metrics, and comments, group insights, and translate them into the product backlog with an assessment of impact.

Checklist

  • Define participant profiles and scenarios.
  • Conduct a pilot session, calibrate the scenarios.
  • Tests with NVDA/VoiceOver/TalkBack and screen magnifiers.
  • Collect metrics and NPS, formulate recommendations.
  • Convert results into prioritized tickets.

Tools

  • ZoomText/Windows Magnifier
  • Screen readers (links above)

Product ticket template

  • Title: Improve navigation in the “Promotions” section
  • Problem: Users using a magnifier lose navigation context.
  • Steps: Test with a 200% magnifier on mobile, search for “Promotions”.
  • Severity: Medium
  • Priority: P2
  • Acceptance criteria: Time on task ↓ by 20% in the retest.

Implementation plan, prioritization and budget

Implementation strategy: discovery (goals, audience), audit (auto + manual), quick wins (contrast, focus, alt, labels, skip links), sprint‑remediation (components, forms, modals), regression testing (CI). Prioritize remediation tickets by impact on users, difficulty of fixing and legal risks.

CAPEX/OPEX: estimate the effort of designers, frontend, QA; factor in time for training. In projects without a full redesign we replace risky patterns without touching the brand DNA: contrast and focus are configured through tokens, forms, components, ARIA, and wrappers.

Checklist

  • Approve the AA scope and the list of pages.
  • Create the backlog and RICE estimates for tickets.
  • Allocate CAPEX (audit + fix) and OPEX (regressions) budgets.
  • Set an SLA for fixing critical regressions.
  • Schedule team training.
Code/snippet (focus token in the design system):

:root { --focus-color: #0a84ff; --focus-width: 2px; }
:focus { outline: var(--focus-width) solid var(--focus-color); }

Tools

  • RICE Prioritization: Intercom framework
  • Jira/YouTrack ticket templates

Product ticket template

  • Title: Enable focus tokens at the design system level
  • Problem: Inconsistent focus in components.
  • Steps: Check Button, Link, Input in Storybook.
  • Severity: Medium
  • Priority: P2
  • Acceptance criteria: Consistent focus across components, Storybook coverage.

Accessibility implementation plan for the website

30 days (small site): audit + quick wins + accessibility statement. 60 days (medium): remediation of components, forms, navigation, automation of checks. 90 days (large): CI/CD, regressions, user testing, updating the design system and documentation.

CI/CD and regression monitoring

Integrate accessibility tests into the pipeline: run the Pa11y/axe-core CLI on key routes, fail the build on critical violations. Add accessibility regression testing: screenshot and DOM snapshots to track contrast, attributes, and roles.

In multisite projects, rely on the design system: “component accessibility” as part of the Definition of Done. Document ownership, SLAs, and the escalation process. In one construction portal with several landing pages we extracted accessibility into tokens and component templates: new sites automatically inherited AA compliance.
Code/snippet (GitHub Actions example):

- name: Pa11y audit
  run: pa11y-ci --config .pa11yci

Checklist

  • Configure CI with error thresholds.
  • Add routes for audit (home, search, cart, checkout).
  • Enable visual regression tests for key screens.
  • Update Definition of Done (WCAG AA).
  • Maintain a public accessibility changelog.

Tools

Product ticket template

  • Title: Add pa11y-ci to GitHub Actions
  • Problem: No automated accessibility checks.
  • Steps: Set up the config, add routes, and thresholds.
  • Severity: Medium
  • Priority: P2
  • Acceptance criteria: The pipeline fails on critical violations.

KPI and accessibility metrics for conversion

Measure: task completion, time on task, conversion rate, reduction in drop-offs, NPS. Link metrics to the funnel: product page → cart → checkout (Nova Poshta + card). Accessibility increases predictability of user flows and reduces cognitive load, which is reflected in the metrics.

Approach to ROI: reducing leaks at each step + fewer support requests + legal protection and reputation. In one pharma e-commerce we recorded a conversion increase of 9–12% in categories where we fixed forms and navigation; with an unchanged media mix, CAC decreased and LTV grew due to repeat purchases.

For reporting, use dashboards: KPIs for WCAG status (number of violations), product metrics, NPS for users of assistive technologies. This creates a complete picture for marketing and product.

Checklist

  • Define baseline metrics and target values.
  • Set up events for assistive patterns (skip link click, zoom, prefers-reduced-motion).
  • Create a dashboard with trends for conversion and drop-offs.
  • Plan A/B tests for contrast/focus/forms.
  • Agree on the monthly report format.
Code/snippet (event for skip link):

document.querySelector('.skip-link')
  ?.addEventListener('click', ()=>analytics.track('skip_link_used'));

Tools

  • Amplitude/Mixpanel/ga4 events
  • Looker/Data Studio for dashboards

Product ticket template

  • Title: Add accessibility event tracking
  • Issue: No data on usage of skip link and zoom.
  • Steps: Set up events, verify in the report.
  • Severity: Low
  • Priority: P3
  • Acceptance criteria: Events in the dashboard, segments are comparable.

Templates and checklists for getting started

Case 1 (B2C e‑commerce, pharma): improved contrast, alt, forms, focus. Result: bounces −12%, conversion +9,3%, NPS among users with the magnifier +11 p.p. Lesson: first: product page and checkout, then categories.
Case 2 (SaaS/fintech): keyboard navigation, focus‑indicators, accessible validation. Result: successful logins +7%, “can’t sign in” requests −16%. Lesson: focus and hints remove barriers faster than a redesign.
Case 3 (news portal): landmarks, typography, skip links. Result: time on task to the target article −25%, viewing depth +18%. Lesson: structure and readability matter more than visual effects.

Ready-made checklists

  • Design: contrast 4.5:1, line length, line-height, color blindness.
  • Development: semantic HTML, focus, skip links, ARIA live.
  • QA: keyboard walkthrough, NVDA/VoiceOver, Lighthouse ≥ 90, WAVE/axe without critical issues.

Resources

Checklist

  • Choose 1 case metric for quick improvement.
  • Approve the set of mandatory design-system components.
  • Create ticket templates for problem categories.
  • Assign owners for each area.
Code/snippet (available tabs):



  
  



...

Product ticket template

  • Title: Implement accessible tabs in the catalog
  • Problem: Tabs implemented as divs; keyboard navigation is missing.
  • Steps: Check arrow keys/Tab; the screen reader does not announce context.
  • Severity: Medium
  • Priority: P2
  • Acceptance criteria: ARIA roles, arrow keys/Enter, NVDA announcements.

Conclusion and call to action

I believe accessibility is a discipline of efficiency. In the end you get: greater reach, predictable conversion, a resilient reputation, and compliance. BUSINESS SITE’s practice shows that quick wins in contrast, focus, forms, and navigation lead to measurable results in one‑two sprints, and a systemic approach through a design system and CI/CD consolidates the effect.

Recommended first steps: 1) conduct a combined audit (axe/Lighthouse + manual), 2) close quick wins on the main flows (catalog → cart → checkout), 3) set AA as the target level and publish an accessibility statement. For marketing it’s transparent: metrics and ROI, for development: a clear backlog, for leadership – managed risk and funnel growth.

If you need a reliable partner to conduct an audit, run a pilot, and set up processes, the BUSINESS SITE team is ready to share its expertise and take responsibility for the result.

Completion checklist

  • Approve AA level and roadmap.
  • Run the audit and close quick wins.
  • Set up regression tests in CI.
  • Publish accessibility statement.
  • Create KPI dashboard.

Product ticket template

  • Title: Publish a public accessibility statement
  • Problem: There is no public commitment or contact.
  • Steps: Prepare the text, add it to the footer, notify the team.
  • Criticality: Low
  • Priority: P3
  • Acceptance criteria: The page is accessible and includes the level, date, and contact.

Frequently Asked Questions

Question 1: Is a complete redesign necessary to become accessible?
Answer: In most cases, no. Quick wins and component adjustments are sufficient; a full redesign is needed if the design system doesn’t support contrast/focus and basic patterns.
Question 2: How much does adapting a website for visually impaired users cost, and how do you estimate timelines?
Answer: For a small site, from 2–4 weeks, medium – 6–10 weeks, large – phased over a quarter. Cost depends on the number of pages/components, the state of the design system and automated test coverage (CAPEX for remediation + OPEX for regression).
Question 3: Which tools are best for quick accessibility checks?
Answer: To start: Lighthouse and WAVE. For depth and CI – axe-core and Pa11y; for reporting and consulting – Tenon.io.
Question 4: How do you prove to a business owner the return on investment in accessibility?
Answer: Show an increase in conversion rate and a reduction in drop-offs after quick wins, record a decrease in support inquiries, and account for legal risk. Logic: CAC ↓, LTV ↑, ROMI of campaigns ↑.
Question 5: How to quickly integrate accessibility tests into CI/CD?
Answer: Add the pa11y-ci/axe-core CLI to the pipeline, define the severity of violations and thresholds. Then include regression snapshots of key pages.

Checklist

  • Use Lighthouse/WAVE for an initial audit.
  • Integrate axe-core/Pa11y into CI.
  • Agree on pipeline failure thresholds.
  • Schedule a training workshop for the team.
  • Add an FAQ to the internal portal.

Product ticket template

  • Title: Prepare an accessibility workshop for the team
  • Problem: Lack of skills, risk of regressions.
  • Steps: Create the program, gather examples, set a date.
  • Criticality: Low
  • Priority: P3
  • Acceptance criteria: Training conducted, materials available, questions collected.

P.S. In my experience, when accessibility becomes part of the Definition of Done, marketing gains a sustained efficiency boost, the product gets a manageable funnel, and the brand gains trust. At BUSINESS SITE we follow this practice across all projects: from pharma e-commerce to fintech services and travel portals.