Designing for Accessibility: Building Digital Products Everyone Can Use

Accessible web design means building websites and apps that people with visual, hearing, motor, and cognitive disabilities can use without help, by following the Web Content Accessibility Guidelines (WCAG). In practice, that comes down to readable contrast, full keyboard support, real labels on forms, text alternatives for images, and code that screen readers can interpret. Get those right and you also get a faster, clearer site for every visitor.

The audience is large. According to the World Health Organization, an estimated 1.3 billion people, or 16% of the world’s population, live with a significant disability. Add older users, people on cracked phone screens in bright sunlight, and anyone with a broken mouse, and the group who benefits from accessible web design becomes most of your traffic.

Most sites still fail. The 2026 WebAIM Million report found detectable WCAG 2 failures on 95.9% of the top one million home pages, with an average of 56.1 errors per page. This guide explains the standards, compares the fixes, gives you a checklist your team can run, and shows the mistakes we see most often in audits.

1. What Accessible Web Design Means for Your Business

Accessibility is a quality attribute of your product, in the same category as speed and security. A page is accessible when a person can perceive its content, operate its controls, understand what is happening, and use it with whatever assistive technology they rely on. That last part matters more than most teams expect, because screen readers such as NVDA, JAWS, VoiceOver, and TalkBack read the code, not the pixels.

Who you are actually designing for

Disability is not one group with one need. A blind user depends on headings, landmarks, and alt text. A user with low vision zooms to 200% or 400% and needs a layout that reflows without sideways scrolling. Someone with a tremor or repetitive strain injury may use only a keyboard, a switch device, or voice control, so every button must be reachable and big enough to hit.

Deaf and hard-of-hearing users need captions on video and transcripts for audio. People with dyslexia, ADHD, or memory impairments need plain language, predictable layouts, and forms that don’t time out halfway through. Temporary and situational limits count too: a broken wrist, a toddler on one arm, a noisy bus.

Where accessible web design starts

It starts earlier than most people think. The decisions that make or break accessibility (color palette, type size, spacing, how a menu opens, how errors appear) are made in wireframes and design systems, long before a developer writes markup. That’s why we treat accessible web design as a design discipline first and a coding task second.

The business case in plain numbers

You can measure the return in three places. First, reach: every barrier you remove opens the site to customers who would otherwise leave. Second, search: many accessibility fixes (descriptive headings, alt text, link text that says where it goes, a declared page language) are also signals search engines and AI answer engines read. Third, legal exposure, which we cover in the next section.

There’s also a cost argument. Fixing contrast in a design file takes minutes. Fixing it after launch across 40 templates and a component library takes a sprint. Teams that treat accessibility best practices as part of design and development, rather than a post-launch audit, spend far less to reach the same result.

Inclusive UX design versus “compliance”

WCAG compliance is the floor. Inclusive UX design is the wider practice of involving people with different abilities in research and testing so the product works well for them in daily use. Passing a checker is a lower bar. A form can pass every automated check and still confuse a screen reader user because error messages appear in the wrong order. Compliance gets you a defensible baseline; inclusive UX design gets you a product people actually prefer to use.

2. The Standards Behind Accessible Web Design: WCAG 2.2, ADA and EAA

You don’t need to read every standard in full, but you should know which one applies to you and what level it asks for.

WCAG 2.2 in brief

WCAG is published by the W3C’s Web Accessibility Initiative. The current version is WCAG 2.2, first published on 5 October 2023 and updated on 12 December 2024. It is organized under four principles, usually shortened to POUR:

• Perceivable: content can be seen, heard, or read by assistive technology (alt text, captions, contrast).
• Operable: everything works with a keyboard, users have enough time, nothing flashes dangerously.
• Understandable: text is readable, behavior is predictable, errors are explained.
• Robust: code is clean enough for current and future assistive tools to interpret.

Each success criterion sits at Level A, AA, or AAA. Level AA is the target almost every law and procurement contract points to. AAA is useful for specific pages (a government form, a health portal) but rarely required site-wide.

What WCAG 2.2 added

WCAG 2.2 added nine success criteria and made 4.1.1 Parsing obsolete. Six of the nine are at Level A or AA, so they apply to most projects:

• 2.4.11 Focus Not Obscured (Minimum), AA: sticky headers, cookie banners, and chat widgets must not completely hide the element that has keyboard focus.
• 2.5.7 Dragging Movements, AA: any drag action (sliders, kanban boards, map panning) needs a single-click alternative.
• 2.5.8 Target Size (Minimum), AA: clickable targets should be at least 24 by 24 CSS pixels, or spaced so they don’t overlap.
• 3.2.6 Consistent Help, A: if you offer help (phone, chat, contact link) on several pages, keep it in the same relative place.
• 3.3.7 Redundant Entry, A: don’t make users type the same information twice in one process; auto-fill it or let them select it.
• 3.3.8 Accessible Authentication (Minimum), AA: logins must not depend on memorizing or solving puzzles unless there’s an alternative, such as allowing password managers and copy-paste.

The other three (2.4.12, 2.4.13, and 3.3.9) are Level AAA.

Laws that reference WCAG

If you sell into the United States, the Department of Justice’s Title II rule adopts WCAG 2.1 Level AA for state and local government websites and mobile apps. Under an interim final rule published on 20 April 2026, governments serving 50,000 or more people must comply by 26 April 2027, and smaller governments and special districts by 26 April 2028 (see the ADA.gov fact sheet). Private businesses in the US also face lawsuits under Title III, where courts and settlements routinely use WCAG AA as the yardstick.

In Europe, the European Accessibility Act covers e-commerce, banking services, e-books, transport services, and several device categories. EU member states had to write it into national law by June 2022. If you build an online store, banking app, or booking platform for European customers, assume WCAG 2.1 AA (through the harmonized standard EN 301 549) is the expected level.

For Bangladeshi companies, the practical point is simple: if your clients or users are in the US, UK, EU, Canada, or Australia, accessible web design is already a contract and legal requirement for many of them. Building to WCAG 2.2 AA from day one covers the older 2.1 requirements as well.

3. Accessibility Fixes Compared: Effort, Impact and Cost Drivers

Not every fix costs the same. The table below uses the six most common failures from the 2026 WebAIM Million data and adds the 2.2 criteria teams most often miss. Effort ratings are our estimates for an existing mid-sized site; your actual effort depends on how many templates and custom components you have.

Two patterns stand out. The six most common failures are cheap to fix, which is why an accessibility sprint on an existing site often clears most automated errors in days. The expensive problems sit in custom JavaScript components and third-party widgets, so that is where your budget and testing time should go.

4. A 12-Step Accessible Web Design Checklist for Your Team

Use this checklist on a new build or an existing site. Steps 1 to 4 belong in design, steps 5 to 9 in development, and steps 10 to 12 in testing and maintenance.

Design phase

1. Pick colors that pass contrast. Body text needs a 4.5:1 contrast ratio against its background; large text (24px regular or about 19px bold) and UI elements like input borders need 3:1. Check every brand color pair in Figma with a contrast plugin before handing off.
2. Don’t rely on color alone. A red border on its own won’t do for error fields; add an icon or a short text message. Charts need patterns or direct labels in addition to color.
3. Design visible focus states. Every link, button, and input needs a clear focus indicator, such as a 2px outline in a contrasting color. Design it in the component library so developers don’t have to invent it.
4. Size targets for fingers. Aim for 44 by 44 pixels on primary actions and never go below the WCAG 2.2 minimum of 24 by 24 CSS pixels. Leave space between icon buttons.

Development phase

5. Use semantic HTML first. A <button> is keyboard-accessible for free; a <div> with a click handler is not. Use real headings (one H1, then H2 and H3 in order), lists, tables with header cells, and landmarks like <header>, <nav>, <main>, and <footer>.
6. Label every form field. Tie each input to a visible <label>. Placeholders disappear once users start typing, so they don’t count. Put error messages next to the field and link them with aria-describedby.
7. Write useful alt text. Describe what the image communicates in context (“Invoice dashboard showing three overdue payments”), not what it is (“image123.jpg”). Decorative images get an empty alt="" so screen readers skip them.
8. Test full keyboard operation. Tab through the whole page. Focus should move in a logical order, never get stuck, and stay visible. Modals must trap focus while open and return it to the trigger when closed. Add a “Skip to main content” link.
9. Use ARIA sparingly and correctly. The W3C’s first rule of ARIA is to use native HTML when it exists. Add aria-expanded to accordion and menu toggles, aria-live regions for status messages like “Item added to cart,” and accessible names on icon-only buttons.

Testing and maintenance phase

10. Run automated checks in CI. Tools such as axe-core, Lighthouse, WAVE, and Pa11y catch a share of issues, mostly the missing-attribute kind. Add axe-core to your test pipeline so a pull request that removes a label fails the build.
11. Test manually with real assistive technology. Automated tools can’t judge whether alt text makes sense or whether focus order is logical. Test key flows (sign-up, checkout, contact form) with NVDA on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Zoom to 400% on a 1280px-wide window and confirm nothing gets cut off.
12. Publish an accessibility statement and keep score. State your target (for example, WCAG 2.2 AA), known gaps, and a contact for reporting problems. Re-audit after every major release, because new content and plugins add new errors.

If you only have time for three steps this month, do 1, 6, and 8. Contrast, form labels, and keyboard support fix the issues that block the most people.

5. Common Accessibility Mistakes That Fail Real Users

We see the same problems across audits, whatever the platform or stack. Most of them come from good intentions applied in the wrong place.

Installing an overlay widget and calling it done

Accessibility overlays (the floating toolbar icons that promise one-line compliance) don’t fix the underlying code. A missing form label is still missing; the overlay just adds another layer that can conflict with the screen reader the user already has. Many disabled users switch them off. Fix the source instead.

Treating accessibility as a final QA task

When accessibility is checked only before launch, the findings arrive as hundreds of tickets nobody has time for. Contrast choices, component behavior, and heading structure are design decisions, so they should be settled in design. Following accessibility best practices from the wireframe stage costs a fraction of retrofitting them later.

Relying only on automated scores

A Lighthouse accessibility score of 100 does not mean a site is accessible. Automated tools cannot tell whether your alt text is accurate, whether a custom dropdown announces its options, or whether a checkout makes sense when read aloud. Use automated tools as a smoke detector and manual testing as the inspection.

Custom components with no keyboard support

Date pickers, mega menus, sliders, and drag-and-drop boards are the usual culprits. They look polished and fail the moment someone presses Tab. If you build custom, follow the patterns in the W3C ARIA Authoring Practices Guide, or use a component library that already handles focus and roles.

Hiding focus outlines for looks

The line outline: none in a stylesheet has probably locked out more keyboard users than any other single line of CSS. If the default ring clashes with your brand, restyle it. Don’t remove it.

Stuffing alt text with keywords

Some teams treat alt text as an SEO field and fill it with phrases like “best software company Dhaka web design.” A screen reader user hears that string read aloud, which is noise. Write alt text for the person listening: one short sentence about what the image shows and why it’s there. Good accessible web design and good SEO agree here, since search engines also reward accurate descriptions over keyword lists.

Forgetting content editors

A site can launch accessible and decay within months if editors upload images without alt text, paste headings as bold paragraphs, or embed uncaptioned videos. Make alt text a required field in your CMS, give editors a one-page guide, and include content checks in your audit cycle.

Ignoring mobile apps

Native iOS and Android apps need the same care. Use the platform’s accessibility labels, support Dynamic Type and font scaling, and test with VoiceOver and TalkBack. Flutter and React Native both expose semantics APIs; they only work if developers fill them in.

6. How Golden Info Systems Builds Accessible Products

At Golden Info Systems, accessible web design is part of how we design and build from the first workshop, so it never shows up as a separate line item at the end. GISL is a BASIS-member software company in Dhaka with 12+ years of experience and 850+ completed projects, and our UI/UX design team works in-house alongside our developers, so accessibility decisions made in design carry through to code.

We follow the same four-phase process on every project:

• Requirements: we confirm your target standard (usually WCAG 2.2 AA), the markets you serve, and any client or procurement rules. If you have an existing site, we start with an accessibility audit of key templates and user flows.
• Planning: we fix the color palette, type scale, focus styles, and component behavior in the design system before building screens. Our UX design process includes wireframing and usability testing, where we check flows with keyboard and screen reader in mind.
• Execution: our web development and mobile teams build with semantic HTML, accessible component patterns, and automated checks in the pipeline. Our stack includes React.js, Angular, Vue.js, Flutter, and Swift, each of which supports accessible patterns when used correctly.
• Delivery: we run manual tests on core user flows, fix what we find, and hand over a short guide so your content editors keep the site compliant after launch.

We also redesign existing websites and apps. If your current product fails contrast, keyboard, or form checks, a focused redesign of the component library often fixes the problem everywhere at once. If you’re still deciding where interface work ends and experience work begins, our guide to UI vs UX design explains how the two fit together.

7. Frequently Asked Questions

What is accessible web design?

Accessible web design is the practice of building websites and apps that people with disabilities can perceive, operate, and understand, including users of screen readers, keyboards, voice control, and screen magnifiers. It follows the W3C’s Web Content Accessibility Guidelines, currently WCAG 2.2. Typical requirements include sufficient color contrast, text alternatives for images, labeled form fields, captions on video, logical headings, and full keyboard operation. Done well, it also makes the site clearer and faster for everyone else.

What does WCAG compliance mean, and which level do I need?

WCAG compliance means your site meets the success criteria at a chosen conformance level: A, AA, or AAA. Level A covers the most basic barriers, AA adds the requirements most laws and contracts reference, and AAA is the strictest. For almost every business, the right target is WCAG 2.2 Level AA. It includes everything in WCAG 2.1 AA, so it satisfies rules that still reference the older version, such as the US Department of Justice’s Title II rule.

How do I check if my website is accessible?

Start with a free automated scan using WAVE, axe DevTools, or Lighthouse in Chrome; it will flag missing alt text, labels, and contrast failures. Then do a manual check: unplug your mouse and complete your most important task using only the Tab, Enter, and arrow keys. Next, turn on a screen reader (NVDA on Windows, VoiceOver on Mac or iPhone) and listen to the same flow. Finally, zoom to 400% and confirm the layout still works.

Is web accessibility a legal requirement?

It depends on where your users are and what sector you serve. In the US, the DOJ’s Title II rule requires WCAG 2.1 AA for state and local governments, and private businesses face lawsuits under Title III. The European Accessibility Act covers e-commerce, banking, transport, and e-books sold to EU consumers. If you export software or serve customers in these markets, treat accessibility as a requirement. This is general information, not legal advice; check with a lawyer for your situation.

How much does it cost to make a website accessible?

There’s no fixed price, because cost depends on site size, the number of templates and custom components, existing code quality, and how much video needs captions. Building accessibility into a new project adds little when it’s planned from the start. Retrofitting an existing site costs more, mainly for custom JavaScript widgets and third-party plugins. A practical approach is an audit of key templates first, which gives you a prioritized list and a reliable estimate before any fixing begins.

Do accessibility overlays or plugins make my site compliant?

No. Overlay widgets add a toolbar that changes font size or contrast, but they don’t repair missing labels, broken keyboard support, or incorrect code underneath. Screen reader users already have their own settings, and overlays can interfere with them. Plugins that help editors (for example, ones that require alt text before publishing) are useful, but compliance comes from fixing the actual templates, components, and content. Treat any product promising instant compliance with caution.

Does accessibility help SEO?

Yes, in several direct ways. Descriptive headings, meaningful alt text, clear link text, a declared page language, captions, and transcripts all give search engines more to understand and index. Clean semantic HTML also helps AI answer engines extract and quote your content accurately. Accessibility doesn’t replace keyword research or link building, but the work overlaps with technical SEO, so fixing one usually improves the other. Faster, simpler pages tend to improve engagement metrics as well.

8. Your Practical Next Step

Pick the one page that earns you the most business (your contact form, product page, or checkout) and run the three checks from this guide today: a WAVE scan, a keyboard-only walkthrough, and a 400% zoom test. Write down every point where you got stuck. That list is the start of your accessible web design plan, and it tells you exactly where your budget should go first.

If you’d like a second pair of eyes, send that list to our team through the Golden Info Systems contact page and ask for an accessibility review and quote. We’ll tell you what to fix, in what order, and what it will take to reach WCAG 2.2 AA.