An accessible interface should retain its meaning, navigation, and essential tasks even when a browser blocks scripts, a connection degrades, or assistive technology interprets the page differently from the designer's expectations.
This guide is part of the NexisHub Modern Web Engineering desk. It connects practical engineering, research, and product decisions to the wider NexisHub platform.
The operating idea
Begin with a mundane task: find a publication, read its description, then follow a reference. A real anchor element handles navigation, focus, browser history, and link semantics. Replacing it with a clickable div discards those capabilities and forces the developer to rebuild them imperfectly.
Progressive enhancement does not prohibit JavaScript. It assigns responsibility carefully. HTML carries structure and the core task; CSS improves visual expression; scripts enhance interaction without becoming the only path to essential information.
NexisHub separates verified platform documentation, repeatable observation, and inference. No optimization can guarantee selection or citation by an external system.
A publication search that degrades gracefully
Use an HTML form with method GET, an explicit search label, and a submit button. Let the server read the query parameter and return filtered results on a normal page URL. When JavaScript is available, you may enhance the form with live suggestions or a loading state; submitting the form must still work if those enhancements fail.
A visually hidden label remains accessible to screen readers when implemented correctly. Placeholder text alone is not a label because it disappears during typing and can have low contrast. Mark validation messages near the related control and describe the required correction in ordinary language.
Interactive controls need the right element
Navigation uses anchors with href. An action that changes local state uses a button. Native form controls already provide keyboard behavior and recognizable semantics. A disclosure may use details and summary if that matches its interaction, but should still be tested with the actual target devices and assistive technology.
When building a mobile menu, manage focus intentionally and report expanded state with aria-expanded. Do not add a collection of ARIA attributes to custom widgets without testing whether native controls would do the job more reliably. JavaScript-only keyboard shortcuts are not a substitute for visible operable buttons.
Test failure modes as ordinary usage
Disable JavaScript and load the core routes. Can a visitor identify the page, read its main content, navigate back to the homepage, and reach contact and legal information? Next, test at 200% zoom, narrow viewports, and keyboard-only operation. Confirm that focus remains visible and follows a logical order.
Use a screen reader to check link names, heading hierarchy, form instructions, validation and announced state changes. Automated audits catch some issues but cannot certify that a full workflow is understandable. Record the device, browser, screen reader and task, and note any obstacle rather than hiding it behind a passing score.
Where exceptions are justified
Some rich experiences genuinely need JavaScript, such as live canvas editors or complex data exploration. Provide a meaningful accessible description, an alternative output or route where feasible, and an honest statement of which operations require scripting. A static fallback must not falsely imply that an interactive workflow completed.
For a research graph, a tabular node-and-edge description can offer a useful alternative to pan-and-zoom visual interaction. For a simulated lesson, a text lesson and ordinary practice questions may preserve the learning objective when the rich widget cannot run.
Core principles
- Semantics before ARIAUse the elements designed for links, buttons, forms, and headings.
- Make the main path resilientKeep reading, navigation and essential submission available without fragile script chains.
- Test by completing tasksEvaluate real keyboard and assistive technology journeys, not only checker scores.
- Describe limitationsProvide useful alternatives where essential script-driven features cannot be replicated.
A practical implementation workflow
Apply the work in a controlled sequence. Keep a baseline, name an owner, and define the evidence that will show whether each step was completed.
- 1. Map essential journeysList reading, navigation, search, help, and submission tasks.
- 2. Implement semantic HTMLChoose native controls and correct heading/label relationships.
- 3. Establish the no-script pathTry core journeys with JavaScript unavailable.
- 4. Add measured enhancementsLayer live feedback, animation or suggestions without changing the fundamental task.
- 5. Test diverse inputsUse keyboard, zoom, mobile touch, and at least one relevant screen reader.
- 6. Record defects and retestTrack each obstacle to a corrected build and repeat the original task.
Common mistakes
Click handlers on non-interactive elements
They commonly omit keyboard support and meaningful state.
Placeholder-as-label forms
They lose context during editing and can make errors confusing.
Accessibility by automated score alone
A checker cannot decide whether a multi-step journey makes sense.
How to measure it responsibly
Define a task matrix with expected path, keyboard outcome, screen-reader outcome, zoom behavior, and JavaScript-disabled outcome. Use pass, fail, or not applicable with a reason rather than an unsupported 'fully accessible' badge.
Document the version and assisted technologies used. The WCAG standard provides testable criteria, but compliance claims require a suitable evaluation process beyond these illustrative steps.
Keep observed outputs, diagnostic scores, inferred causes, and business outcomes in separate fields. A modelled score is not a citation, and correlation is not proof of cause.
What comes next
As interfaces grow richer, the strongest accessibility strategy is to keep semantics and alternatives near the product requirement, not bolt them on after launch.
The durable response is to build pages that are accessible, semantically explicit, useful outside their original layout, and backed by evidence a reader can inspect.
Key takeaways
01Use links for navigation and buttons for actions.
02Keep basic content useful without scripting.
03Test keyboard, zoom and screen readers against named tasks.
04State the boundary where a rich feature requires JavaScript.
Frequently asked questions
Does progressive enhancement mean no JavaScript?
No. It means essential tasks have a useful baseline and scripting improves the experience when available.
Is adding aria-label enough to make a widget accessible?
No. Focus handling, role, interaction behavior and meaningful task completion also matter.
Can a complex graph be accessible?
It may need alternate data representations and tested keyboard controls; a static list or table can preserve important information.
References and further reading
Turn a useful idea into a maintainable product.
Nexis Studio helps organisations move from problem definition to product design, engineering, launch, and long-term support with clear technical and commercial boundaries.
Explore Nexis Studio