Accessibility and performance
Accessibility and speed are part of the build
Two things decide whether a digital product is pleasant to use: whether people can use it at all, and whether it responds quickly. Accessibility and performance are often treated as optional clean-up tasks. In practice they are design and engineering decisions that are cheaper to make early and expensive to retrofit.
Why accessibility is becoming a default requirement
Accessibility means building interfaces that work for people with different needs: those using screen readers, keyboard navigation, larger text, or reduced motion settings. The Web Content Accessibility Guidelines, usually shortened to WCAG, provide a widely recognised structure for this, organised around principles like perceivability, operability, and understandability.
Singapore agencies increasingly list accessibility alongside performance in their web application work, and it is now a normal consideration in interface and product planning rather than a specialist add-on. That shift matters for budgets: a screen-reader path or a visible focus state is far easier to add while layouts are still fluid than after a build has shipped.
Screen reader users
Headings, labels and landmark regions are what makes a page navigable by voice rather than by eye.
Keyboard-only use
Every control needs a visible focus state and a sensible order, including menus, dialogs and form steps.
Larger text and zoom
Layouts that survive 200% zoom without clipping or overlapping keep the content reachable for low-vision readers.
What WCAG asks for in practice
WCAG is a set of guidelines rather than a checklist, but several items come up constantly. These are specific, testable requirements, and most of them are settled during design rather than after launch.
- Text contrast
- Body copy and interface labels need enough contrast against the surface behind them. Light grey placeholder text on white is the most common failure, and it is usually a token problem, not a design decision.
- Alternative descriptions
- Images need alternative descriptions where they carry meaning. Decorative images are marked so assistive technology can skip them instead of reading noise.
- Form labels and errors
- Forms need labels tied to their fields and clear error messages that say what went wrong and how to fix it. An error colour alone does not tell a screen reader user anything.
- Keyboard reachability
- Interactive elements need to be reachable and usable with a keyboard: buttons, links, tabs, accordions, date pickers and anything inside a modal window.
- Colour is not the only signal
- Content should not rely on colour alone to convey information. A red border on an invalid field needs text beside it; a status chip needs a word, not just a hue.
Fixing accessibility and performance together is usually less work than fixing them one at a time.
Heavy images and third-party scripts slow a page down and often lack proper labels or semantics. Poorly structured markup confuses assistive technology and can also hurt rendering. Treating the two as one workstream avoids the situation where a performance fix breaks an accessibility feature, or the reverse.
Performance: what users actually notice
Performance is measured in many ways, but users notice a few things: how long until something appears, how long until they can interact, and whether the page jumps around while loading. A site that looks fast on a developer's machine may behave differently on a mid-range phone over a mobile network, which is the realistic condition for many users in Singapore and elsewhere.
Testing on real devices, not just a desktop browser, gives a more honest picture. It also surfaces the parts of a build that quietly grow over time: unoptimised hero images, a chat widget loaded on every page, a font file requested in several weights that are never used.
Time to first paint
How long a visitor stares at a blank screen before anything appears at all.
Time to interact
How long before taps and clicks actually do something instead of being ignored.
Layout shift
Whether text and buttons jump while images or ads load in behind them.
Practical checks during a project
Teams can run useful checks without specialist tooling. None of this requires deep expertise, only the habit of doing it before release rather than after a complaint.
-
1
Throttle the connection and watch
Load key pages on a slowed-down connection and observe the order things appear in. What shows up first tells you what the build treats as important.
-
2
Navigate the whole product by keyboard
Put the mouse aside and tab through every screen. If you lose track of where the focus is, or get trapped inside a menu, users will too.
-
3
Turn on a screen reader for a few minutes
Try to complete one core task, such as finding a price or sending a message, using voice only. It is uncomfortable at first and very revealing.
-
4
Audit images and forms
Check images for missing alternative text and forms for missing labels. Both are quick to find with browser developer tools and quick to fix before launch.
-
5
Run a performance audit on the busiest pages
Look at the largest elements on the page and any layout shift. Fix the biggest image or script first; small wins on a heavy page rarely change how it feels.
Where accessibility and performance overlap
The two topics share causes. A single unoptimised hero image can slow the page and arrive without a useful description. A third-party script that loads late can shift the layout under a button a user is about to press, which is a usability problem and a technical one at the same time.
Structured markup is the clearest example. Semantic headings, lists and labels help assistive technology understand a page, and they also give the browser less guesswork to do while rendering. When a team reviews both at once, the fixes tend to reinforce each other instead of competing for release time.
Planning for both from the start
Accessibility and performance should appear in the requirements, the design review, and the acceptance criteria. That means agreeing on a target level of WCAG conformance if one is relevant to your organisation, and setting a realistic performance goal for the pages that matter most.
Making these explicit turns them into shared expectations rather than one person's concern. It also gives a project a fair way to say no to a request that would quietly break either one.
Read how websites are builtRequirements
Write the target down
Name the conformance level you are aiming for and the pages that matter most. An unstated goal cannot be reviewed.
Design review
Catch it on the canvas
Contrast, focus states and control sizes are cheapest to change while the layout is still being drawn.
Acceptance criteria
Agree what done means
A feature is finished when the keyboard path works and the page still responds well on a mid-range phone.
Maintenance
Keep the habit going
New content and new third-party scripts can undo earlier work. Plan for periodic checks rather than a one-time pass.
Testing after launch
Accessibility and performance are not one-time passes. New content, new features, and new third-party scripts can undo earlier work. Periodic checks, ideally on the same core user journeys, catch regressions before users report them.
If your team has an ongoing maintenance arrangement, this is a natural thing to include in it. Re-testing the same five or six journeys every few months is usually enough to notice when something has quietly got heavier.
- Re-test the same core journeys so results stay comparable between rounds.
- Watch for new third-party scripts, which are a common source of slowdowns.
- Check new templates for headings, labels and alternative text before publishing.
- Note what changed between rounds so a fix can be traced back to its cause.
Questions teams ask about accessibility and performance
Do we need to meet a specific WCAG level?
Not every project needs a formal conformance target, but many organisations are asked for one by procurement or legal teams. If a level is required, it should be written into the requirements early so it can be reviewed alongside the design, not measured after launch. If no level applies to you, agree on the specific checks you will run and write those down instead.
How do we test performance without special tools?
Browser developer tools are enough for a first pass. Load your main pages with the network throttled, look at what arrives first and what arrives last, and check whether the layout moves while loading. Then open the same pages on a mid-range phone over mobile data. The difference between a desktop browser and a real device is usually where the useful information is.
Can accessibility be added after the site is built?
Some of it can, and contrast or missing labels are usually quick to correct. Structural problems are harder: keyboard traps inside menus, headings used purely for visual size, or a checkout flow that only works with a pointer. These often mean rebuilding part of a component rather than adjusting a style, which is why the design stage is the cheaper place to deal with them.
Does a fast site stay fast?
No, and that is expected. Pages gain weight as content is added, images are uploaded without resizing, and marketing tools are installed one at a time. A short periodic review on the same pages is usually enough to catch the drift before visitors notice it. Teams with a maintenance arrangement often fold this into the regular work rather than treating it as a separate project.
A question about accessibility or performance?
If you are planning a web application or a mobile app development project and want to know which checks apply to your situation, get in touch. We are happy to talk through what to prepare and where the risks usually sit. You can reach ViewCircuit Digital at 71 Robinson Road, #14-01, Singapore 068895, by phone on +65 6211 3173, or by email at [email protected] during office hours, Monday to Friday, 9:00 AM to 6:00 PM.
Related reading: How Websites Are Built and Native, Cross-Platform and Hybrid Apps.