Web Accessibility Basics: How to Design for Everyone

TLDR: What will you learn

• Accessibility widens your reach and improves usability for all, not just users with disabilities.
• WCAG sounds intimidating but boils down to a few sensible principles.
• Colour and contrast are the fastest wins you can ship today.
• Keyboard access and screen reader support are non-negotiable for real usability.
• Forms are where most sites quietly fail people; labels and errors matter.
• You cannot fix what you do not test, so build testing into your workflow.

Let us make “design for everyone” mean what it says.

Why Accessibility Belongs at the Heart of Web Design

As Tim Berners-Lee, W3C Director and inventor of the World Wide Web, put it, “the power of the Web is in its universality; access by everyone regardless of disability is an essential aspect.” Yet many teams still treat accessibility as a compliance chore bolted on at the end, for a small minority of users. That thinking is exactly what holds most Singapore teams back, and it is wrong on almost every count.

Accessibility in web design does not narrow your reach; it widens it. Designing for everyone means more people can actually use what you build.

The human case

Roughly one in six people worldwide, around 1.3 billion or 16% of the population, live with a significant disability, whether that is low vision, hearing loss, limited motor control, or a cognitive difference (WHO). That is not a fringe group; that is a huge slice of your audience.

Then add ageing users. Singapore is ageing fast, and older adults often deal with smaller text becoming unreadable, shaky taps on tiny buttons, and low patience for cluttered layouts.

Accessibility also covers situational limits that hit all of us. Reading a bank app in bright afternoon sun outside a hawker centre, or tapping through a form one-handed because your other arm is in a cast, are moments where good contrast and large touch targets suddenly matter to you too.

The business and Singapore case

There is a strong commercial reason to care. Accessible markup, clear headings, descriptive alt text, and logical structure overlap almost perfectly with what search engines reward, so accessibility work quietly doubles as SEO work.

You also expand your addressable market. Every user you exclude with poor contrast or unlabelled buttons is a customer, a citizen, or a patient who gives up and goes elsewhere.

The Singapore context makes this pointed. The Enabling Masterplan and SG Enable’s push for a more inclusive society set a clear national direction, and IMDA’s Digital for Life and Digital Readiness efforts assume that essential digital services are usable by everyone, not just the confident and able-bodied.

Picture an 80-year-old trying to check their CPF balance or reset a bank password on a small phone screen. If the text does not scale, the buttons crowd together, and error messages are vague, that person is locked out of a service they are entitled to use.

Accessible design is simply good UX

Here is the mindset shift I want you to hold onto: accessible design is not a separate discipline sitting beside user experience. It is good UX, full stop, and if you are still fuzzy on that, it helps to understand the real difference between UI and UX first.

When you design for the person facing the hardest conditions, you make the product easier for everyone. That principle is what the practical guidelines in the rest of this article are built on.

WCAG Explained in Plain English

When people first hear about accessibility in web design, the acronym WCAG usually pops up and immediately sounds like something a lawyer wrote. It isn’t.

WCAG stands for the Web Content Accessibility Guidelines, and beneath the jargon, it is really just a checklist of common-sense outcomes: can people see it, use it, understand it, and will it keep working across different devices and assistive tools?

Everything in WCAG hangs off four principles, often shortened to POUR. Let me walk you through each one with an everyday example.

Perceivable

Users must be able to sense your content in some way. For example, a product photo needs alt text so a screen reader user knows it shows a red running shoe, not just “image”.

Operable

People must be able to navigate and interact using whatever input they have. A checkout button should work with a keyboard alone, so someone who cannot use a mouse can still complete a purchase.

Understandable

Content and controls should behave predictably and read clearly. If a form field rejects an entry, the error message should say “Enter a valid Singapore postal code” rather than a cryptic “invalid input”.

Robust

Your site should work reliably across browsers, screen readers, and future tools. Using clean, standard HTML rather than messy custom code helps assistive technology interpret your pages correctly.

Conformance Levels: Why AA Is the Sweet Spot

WCAG grades success into three levels. Level A is the bare minimum, Level AA is the practical target most organisations aim for, and Level AAA is the strictest, often impossible to meet across an entire site.

Level AA is the sensible default because it covers the barriers that affect the most people without demanding perfection. In Singapore, public sector sites aligning with government digital service standards generally work towards AA, so it is a solid benchmark for private businesses too.

You will also see version numbers like WCAG 2.1 and the newer WCAG 2.2. Think of these as updates that added guidance for mobile, touch, and cognitive needs. If you build against 2.2 at AA level, you are in good shape.

A Quick SME Scenario

Picture a small Singapore fashion label running a Shopify store. The owner decides to audit the site against WCAG 2.2 AA before a big campaign.

Working through POUR, she finds product images missing alt text, low-contrast grey pricing that fails perceivability, and a filter menu that a keyboard cannot reach. None of these are dramatic legal problems; they are fixable gaps that were quietly turning away customers.

Fixing them is largely a design and content exercise, which is why a grounding in tools like Figma helps. If you are starting, our guide to Figma design basics every beginner should master is a good companion.

Treat WCAG as a friendly checklist of outcomes, not an intimidating regulation, and AA becomes a realistic goal for almost any team.

Colour and Contrast That Everyone Can Read

When people think about accessibility in web design, they often picture screen readers first. But some of the most common barriers are visual, and they hit users with low vision or colour blindness every single day.

Colour is one of the easiest things to get wrong and one of the easiest to fix once you know what to look for.

Meeting contrast ratios

The Web Content Accessibility Guidelines (WCAG) set clear contrast targets at the AA level: a ratio of 4.5:1 for normal body text and 3:1 for large text, which WCAG defines as 18pt (roughly 24px) regular, or 14pt bold (roughly 19px) and up.

Contrast ratio simply measures how different your text colour is from its background. Light grey text on a white background might look elegant in a mockup, but for someone with reduced vision it can be nearly invisible.

I always test contrast before sign-off, not after. Free tools make this painless: the WebAIM contrast checker lets you paste two hex codes and see an instant pass or fail, and Figma plugins like Stark or Contrast let you check swatches without leaving your design file.

Not relying on colour alone

Colour should never be the only way you communicate meaning. Around 1 in 12 men have some form of colour vision deficiency, so red and green can look almost identical to them.

Picture a Singapore fintech app showing account status with a red dot for “payment failed” and a green dot for “paid”. A colour-blind user staring at that dashboard cannot tell which invoices need action, which in a financial product is a real problem.

The fix is straightforward: pair colour with a second signal. Add a cross icon and the label “Failed” to the red state, and a tick with “Paid” to the green one.

Do the same across your interface:

• Show form errors with an icon and a text message, not just a red border
• Underline links inside body text so they are visible without colour
• Add patterns or labels to chart segments, not colour swatches alone
• Mark required fields with an asterisk and the word “required”

This one habit removes a huge slice of exclusion, and it costs you nothing but a little intention.

Choosing accessible palettes

Your brand palette has to earn its place in the interface, not just on the pitch deck. A colour can be beautiful and still fail as text.

Take Equinet’s own navy and orange. Navy text on a light background reads clearly, but orange text on cream can slip below 4.5:1 and become hard to read.

So we test brand colours the way we would any other, and reserve weaker combinations for large headings or decorative blocks rather than paragraph text. Aesthetics and legibility are not the same goal, and accessible design demands both.

Designing for Keyboards and Screen Readers

When I first started auditing sites, I assumed everyone browsed the way I did, with a mouse and a trackpad. That assumption falls apart the moment you watch someone navigate a checkout using only the Tab key, or listen to a screen reader read a form aloud.

Plenty of people never touch a mouse. They use keyboards, switch devices, or screen readers like NVDA, JAWS, and VoiceOver. Good accessibility in web design means your site works completely through these tools, not just partly.

Logical focus order and visible focus states

When you press Tab, focus should move through the page in an order that makes sense: header, then main content, then footer, following the visual reading flow.

I have seen sites where Tab jumps from the logo straight to a footer link, then back up to a search box. That disorientation makes the page unusable for keyboard users.

The most common mistake I still catch is designers removing the focus outline because they think it looks messy. Please do not do this. That blue ring is how a keyboard user knows where they are on the page.

If the default outline clashes with your brand, style it instead. Give it a custom colour or a thicker border, but never set `outline: none` without a visible replacement.

Semantic HTML and landmarks

Screen readers rely on the structure of your HTML to describe a page. Using real elements like `<nav>`, `<main>`, `<header>`, and proper heading levels creates landmarks that users jump between, the same way a sighted user scans with their eyes.

If you build everything out of `<div>` tags, a screen reader announces a flat wall of text with no signposts. Using one `<h1>` followed by logical `<h2>` and `<h3>` levels gives everyone a mental map.

This structure also helps search engines. Google crawls semantic markup and heading hierarchy to understand your content, so accessible pages tend to be more crawlable too.

Alt text and ARIA done right

Alt text should describe purpose, not appearance. For a product photo linking to a page, write what the image does, not that it is a decorative flourish. Purely decorative images should carry empty alt text so the screen reader skips them.

ARIA attributes are powerful, but they are a last resort. If a native HTML element does the job, use it.

A real `<button>` already tells assistive tech it is clickable, so wrapping a `<div>` in ARIA roles just to fake a button creates work and bugs.

Accessible Forms, Labels and Error Handling

If there is one place where accessibility in web design falls apart, it is the humble form. I have watched screen reader users abandon perfectly good websites because a single OTP field had no label.

Forms are where people give you their money, their personal data, and their trust. Get them wrong, and you lock people out at the exact moment they are trying to do business with you.

Labels that stay put and stay linked

Picture a Singpass-linked government form asking for your NRIC and a one-time password. The visual designer, chasing a clean look, uses placeholder text inside the field instead of a visible label.

As soon as you start typing, that placeholder disappears. Now a sighted user has forgotten what the field is for, and a screen reader user may never hear it announced.

Always give every field a visible, persistent label that does not vanish when the user interacts with it. Placeholder-only inputs are one of the most common accessibility failures I see in local banking and government flows.

Visible is not enough on its own. The label must be programmatically associated with its input, so a screen reader reads “One Time Password, edit text” rather than just “edit text”.

• Use a proper label element tied to the input by its id, or an aria-label where a visible label is not possible.
• Mark required fields with both a visual indicator and text or an aria-required attribute, not colour alone.
• Group related fields, such as a residential address block, so assistive tech announces them as one logical set.

Errors that name the problem and the fix

Now imagine that same form rejects your input with a lone red message: “Invalid input.” A sighted user squints and guesses. A screen reader user hears nothing at all if the error was never announced.

Vague errors are cruel. A good inline message names the field, states what went wrong, and tells the person how to fix it: “NRIC must start with S, T, F, G, or M followed by seven digits.”

Place that message right beside the field, tie it to the input, and make sure validation announces the error to assistive technology using a live region so it is spoken aloud when it appears.

Small details that help everyone on mobile

Add autocomplete attributes to fields like name, email, and postal code. This lets a bank onboarding flow autofill from a saved profile, which speeds things up for everyone and reduces typos.

Finally, size your touch targets generously. A checkbox or submit button that is too small to tap reliably frustrates a busy CPF user on a phone as much as it blocks someone with limited motor control.

Writing and Structuring Content for Clarity

When we talk about accessibility in web design, most people picture colour contrast or alt text. But how you write and structure your words matters just as much, because dense, jargon-heavy content raises the cognitive load for everyone.

This hits harder in Singapore than you might think. We serve a genuinely multilingual audience where English may be a second or third language, alongside older users who prefer plain instructions over clever copy.

Write in plain language

Keep sentences short and lead with the action. If a reader has to parse a long clause to work out what to do next, you have already lost some of them.

Picture a polyclinic explaining how to book an appointment. Instead of “Patients are requested to ensure prior registration is completed via the designated portal,” write “Book your appointment on the HealthHub app. You will need your Singpass to log in.”

That second version works for a 70-year-old caregiver, a foreign domestic worker, and a busy parent alike. Clarity is not dumbing down; it is respect for your reader’s time.

Structure with meaningful headings and links

Screen reader users often navigate a page by jumping between headings, so your heading hierarchy needs to be logical. Use one H1, then H2s for main sections and H3s beneath them, never skipping levels just to get a bigger font.

Descriptive link text is another quick win. A link that says “click here” tells a screen reader user nothing, while “download the appointment checklist (PDF)” tells them exactly where they are going.

A few habits make content clearer for everyone:

• Break long instructions into numbered steps
• Use headings that describe the content, not vague labels like “More info”
• Give links descriptive text that makes sense out of context
• Add generous line spacing and paragraph breaks so text does not feel like a wall
• Avoid unnecessary acronyms, or spell them out on first use

Captions, transcripts, and readable layout

If you publish a video, add captions and a transcript. Captions serve deaf and hard-of-hearing users, but they also help the commuter watching your explainer on mute during a crowded MRT ride, which is a real chunk of your Singapore traffic.

Generous spacing and readable line lengths reduce fatigue for users with dyslexia and for anyone reading on a small phone screen.

Here is the bonus: clear structure helps your SEO too. Search engines read your heading hierarchy and descriptive links to understand your page, so the same choices that aid accessibility also help you build a content strategy that boosts your SEO.

Testing Your Site for Real Accessibility

Here is the uncomfortable truth I learned early: you cannot assume your site is accessible just because you followed the guidelines. Accessibility in web design has to be verified, not taken on faith.

A page can pass every rule in your head and still trap a screen reader user on a broken form. The only way to know is to test, and to test in three layers that each catch what the others miss.

Automated tools

Start with automated scanners because they are fast and free. I run axe, WAVE, and Lighthouse on almost every project I touch.

axe is a browser extension that flags missing alt text, low contrast, and unlabelled buttons in seconds. WAVE gives you a visual overlay so you can see problems in context, and Lighthouse (built into Chrome DevTools) rolls an accessibility score into its wider audit.

Here is the catch. Automated tools only catch a fraction of real accessibility issues, often cited as around a third; the UK Government Digital Service found even the best tools detect only about 30 to 40%. They will tell you a button has no label, but they cannot tell you whether your label actually makes sense to a human.

Manual checks

This is where you do the work no robot can do. Two manual checks reveal most of the remaining problems.

First, unplug your mouse and navigate the entire site using only the keyboard. Tab through every link, form field, and menu, and confirm the focus indicator is always visible and the order makes sense.

Second, zoom the page to 200 percent in your browser. Text should reflow without content getting cut off or buttons overlapping, which matters hugely for anyone with low vision.

I also test with a screen reader like NVDA or VoiceOver, listening to how the page is announced. It is humbling how often a layout that looks perfect sounds like nonsense.

Testing with real users

Nothing replaces watching an actual person use your site, especially people with disabilities. A user who relies on a screen reader daily will spot friction you would never predict, and their feedback is worth more than any score.

If you are hiring UX talent to lead this, knowing how candidates think about inclusive testing is telling. It is a theme that comes up in these ten UX designer interview questions that hiring managers ask.

A Singapore scenario

Picture a local SME, say a family-run logistics firm, using Enterprise Singapore’s Productivity Solutions Grant (PSG) to fund a digital revamp. Too often, accessibility is an afterthought bolted on the week before launch.

Instead, write an accessibility audit directly into the project scope with your vendor. Specify automated scans, keyboard and zoom checks, and at least one round of testing with users who have visual or motor impairments as a deliverable.

Because the work is scoped and funded from the start, you are not scrambling later. Embed testing into every sprint, not a single rushed check before go-live. Each time you ship a new feature, run the same three layers, and accessibility becomes a habit rather than a fire drill.

Building Accessibility Into Your Design Process

The teams that struggle most with accessibility in web design are the ones who treat it as a final checklist before launch. By then, the colours are locked, the layouts are built, and fixing anything means costly rework.

The fix is to move accessibility upstream, so inclusive design becomes the default rather than a scramble at the end.

Start With An Accessible Design System

The single highest leverage move is a shared design system with accessible components baked in.

Picture a small product team at a Singapore SME, say a local logistics startup building a shipment tracking portal. Instead of designing buttons and form fields from scratch each sprint, they build a component library where every button already meets colour contrast requirements, every input has a visible label, and every focus state is clearly styled.

Once that library exists, every new feature ships inclusive by default. A junior designer dragging in a form field does not need to remember the rules, because the rules live inside the component.

Hand Off With Clear Annotations

Designers still need to communicate intent, and this is where annotated handoffs matter. In Figma, I annotate heading levels, tab order, alt text for images, and the accessible name for icon-only buttons, so developers are not guessing.

If your team is still learning how to structure these handoffs, it helps to understand what Figma is used for in real design teams and how annotation layers keep accessibility decisions from getting lost.

Then make it stick by adding an accessibility checklist to your Definition of Done. A feature is not finished until someone confirms keyboard navigation works, contrast passes, and screen reader labels read correctly.

Share Ownership Across The Team

Accessibility fails when one person is expected to catch everything. It works when ownership is spread across roles:

• Designers own colour contrast, focus states, and touch target sizes.
• Developers own semantic markup, keyboard support, and ARIA when needed.
• Content writers own plain language, meaningful link text, and descriptive alt text.

When each role knows its slice, nothing falls through the gap between design and build.

To embed this capability in-house rather than depending on external audits, upskill your designers. SkillsFuture-funded UX training can help a team learn accessible design patterns properly, so the knowledge stays with your people long after the course ends.

Accessibility is a culture and a habit, not a project you finish once. The teams that treat it as an ongoing practice, reviewed every sprint and built into their system, are the ones that quietly ship better, more sustainable UX for everyone over the long term.

Conclusion

When we started this article, I made the case that accessibility in web design is not a niche add-on bolted on at the end. It is a standard that lifts the experience for everyone, and I hope by now you can see that clearly.

Think back over the throughline we covered. We anchored everything in WCAG’s POUR principles: perceivable, operable, understandable, and robust.

From there we worked through colour and contrast, keyboard and screen reader support, accessible forms, clear content, and continuous testing. None of these are exotic. They are habits any team can build into a normal workflow.

The good news is that better accessibility usually means better UX for all your users. A form that reads well to a screen reader is also easier for a distracted commuter tapping through on the MRT.

For a Singapore business, the case is even stronger. Wider reach across age groups and abilities, cleaner semantic markup that search engines reward, and alignment with our national push towards an inclusive Smart Nation all point the same way.

So do not wait for a big redesign. Start small this week: fix one low-contrast button, or unplug your mouse and try to complete your checkout using only the keyboard.

That single keyboard test often reveals more than an hour of theory ever could. Do it once, and you will never look at a hover-only menu the same way again.

If you want to go deeper and build these skills properly, structured training beats trial and error. I would encourage you to explore the UX Design Career Programme at Equinet Academy, where you practise accessible, user-centred design on real projects rather than slides.

It is the logical next step because designing for everyone is a craft, and the fastest way to master it is hands-on, with feedback, on work that mirrors the real world.