Accessibility at UserDent

Accessibility is not an extra

UserDent believes access to the web should not depend on how someone sees, hears, moves, reads, remembers, communicates, or uses technology.

That belief is not a marketing angle. It is a design obligation.

A website can be fast, polished, and profitable while still excluding people. When that happens, the work is unfinished. Accessibility belongs in the first wireframe, the content model, the component system, the code review, and the launch checklist—not in a patch added after someone encounters a barrier.

We reject the idea that accessibility is optional work to be traded away when a schedule gets tight. We also reject “good enough” as a stopping point when a barrier is known and fixable. Every shortcut becomes someone else’s friction. Sometimes it becomes complete exclusion.

Our standard is simple: build with care, test beyond automation, listen when someone identifies a problem, and keep improving.

Our commitment

For UserDent’s own website and the websites we build, we work toward:

• a 100 Lighthouse accessibility score on representative production pages;
• WCAG 2.2 Level AA as the minimum conformance target;
• every applicable WCAG 2.2 Level AAA success criterion that can responsibly be satisfied for the content and product;
• semantic HTML before ARIA;
• complete keyboard access;
• useful screen-reader output;
• readable content at high zoom and text spacing;
• sufficient contrast in default, hover, focus, active, disabled, and error states;
• alternatives for meaningful visual, audio, and motion-based information;
• clear forms, errors, instructions, and status messages;
• reduced-motion support and no interaction that depends on motion alone;
• recurring review after launch, not one-time certification theater.

WCAG conformance requires more than an automated scan. W3C explains that testing combines automated checks with human evaluation by people who understand how disabled people use the web.[1] That is why Lighthouse is a baseline in our process, never the finish line.

Why we do not make a careless blanket AAA claim

We aim high, including AAA. We also refuse to turn accessibility into an unsupported badge.

W3C defines three conformance levels: A, AA, and AAA. To claim a level, a page must satisfy every success criterion at that level and all lower levels. W3C also advises against requiring Level AAA as a general policy for entire sites because some content cannot satisfy every AAA criterion.[1]

So our public commitment is precise:

1. AA is the minimum target.
2. AAA criteria are reviewed deliberately, not ignored.
3. Every applicable AAA criterion is pursued where the content and product allow it.
4. Exceptions, open issues, and dependencies should be documented rather than hidden.
5. No score or badge substitutes for a person being able to use the site.

That standard is more demanding than claiming “compliance” after running one scanner. It requires evidence, judgment, manual testing, and continued ownership.

What 100 Lighthouse means to us

A perfect automated score is useful because it catches preventable failures and creates a measurable release gate. It can identify issues such as missing accessible names, invalid ARIA, insufficient contrast, missing form labels, and broken document structure.

But automated tools cannot reliably decide whether:

• alternative text communicates the right meaning;
• heading structure makes sense to a reader;
• focus order follows the task;
• instructions are understandable;
• a screen-reader announcement arrives at the right moment;
• an interaction is exhausting or confusing;
• captions are accurate;
• keyboard operation is practical, not merely possible;
• content uses unnecessarily difficult language;
• a person can complete the full journey without help.

For us, 100 means the automated layer is clean enough to move into deeper testing. It never means testing is over.

Standards we use

Our primary technical reference is the official Web Content Accessibility Guidelines (WCAG) 2.2 from the W3C Web Accessibility Initiative.[2]

We organize work around WCAG’s four principles:

Perceivable

Information and interface components must be available in forms people can perceive. This includes text alternatives, captions, adaptable structure, meaningful reading order, contrast, responsive reflow, and content that remains usable when text is enlarged or spacing changes.

Operable

People must be able to operate the interface with the input method available to them. This includes keyboard access, visible focus, practical target sizes, enough time, safe motion and flashing behavior, consistent navigation, and alternatives to dragging or path-based gestures.

Understandable

Content and interaction should be clear and predictable. We use descriptive labels, consistent patterns, plain language, useful instructions, prevention for consequential errors, and error messages that explain how to recover.

Robust

Pages should communicate reliably with browsers, assistive technologies, and future user agents. We favor native elements, valid structure, restrained ARIA, accessible names, programmatic relationships, and status messages that assistive technology can announce.

How accessibility enters our workflow

1. Discovery and content

We identify essential user journeys, likely access needs, content formats, third-party dependencies, and legal or organizational requirements. We ask what a visitor must be able to accomplish—not only what the page should look like.

Content is planned for clear headings, descriptive links, concise instructions, useful error messages, meaningful image alternatives, transcript and caption needs, and reading order.

2. Design

Accessibility is built into design tokens and reusable components. We review color contrast, type size, line length, spacing, focus presentation, target size, state changes, error treatment, responsive reflow, motion, and dark-mode behavior.

Color never carries essential meaning by itself. Hover is never the only way to discover information. Focus is designed, not left to chance.

3. Development

We begin with semantic HTML. Buttons perform actions. Links navigate. Headings describe structure. Lists are lists. Form controls have programmatic labels. Tables are used for tabular data, not layout.

ARIA is added only when native HTML cannot express the required relationship or state. Custom controls must reproduce expected keyboard behavior, naming, state, and focus management before they are considered complete.

4. Automated testing

Representative pages and reusable components are checked with automated tools, including Lighthouse and axe-based testing where appropriate. Automated failures block release until resolved or documented with a technically sound reason.

5. Manual testing

Manual review includes, as applicable:

• keyboard-only navigation in logical order;
• visible focus and focus restoration;
• skip links and landmark navigation;
• screen-reader reading, names, roles, states, and live announcements;
• browser zoom to 200% and 400%;
• narrow viewport and responsive reflow;
• increased text spacing;
• forced-colors and high-contrast behavior;
• reduced-motion preferences;
• contrast across all component states;
• form instructions, validation, errors, and success messages;
• pointer target size and spacing;
• captions, transcripts, audio description, and media controls;
• link purpose, heading clarity, and plain-language review;
• complete task journeys, not isolated components.

6. Launch and maintenance

Accessibility can regress when content, plugins, embeds, campaigns, or components change. We therefore treat it as ongoing maintenance. Important templates are rechecked after material changes, and reported barriers are triaged as product defects.

Design and engineering requirements

Structure and navigation

• One clear page title and a logical heading hierarchy.
• Landmarks for major regions.
• A mechanism to bypass repeated navigation.
• Consistent navigation and component identification.
• Descriptive link text that makes sense in context.
• No positive tabindex values used to force an artificial order.
• Focus never trapped except inside a correctly managed modal interaction.

Keyboard and focus

• Every interactive function works without a mouse.
• Focus indicators remain visible against every background and state.
• Opening a dialog moves focus into it; closing restores focus sensibly.
• Hidden content does not remain keyboard-focusable.
• Sticky elements do not cover focused controls.
• Keyboard shortcuts do not interfere with assistive technology.

Images, icons, and media

• Informative images receive meaningful alternatives.
• Decorative images are hidden from assistive technology.
• Complex charts receive an equivalent explanation or data view.
• Icon-only controls receive accessible names.
• Prerecorded media receives accurate captions or transcripts as required.
• Autoplay, flashing, and unexpected sound are avoided.

Forms and errors

• Every field has a persistent, programmatically associated label.
• Required status and input purpose are communicated in more than color.
• Instructions appear before they are needed.
• Errors identify the affected field and explain a correction.
• Error summaries can move focus and link back to fields when appropriate.
• Submitted data is not discarded after a recoverable error.
• Consequential actions provide review, confirmation, or reversal.

Motion and interaction

• Reduced-motion preferences are respected.
• Motion is never necessary to understand content or complete a task.
• Dragging has a non-drag alternative.
• Pointer gestures have keyboard and simple-pointer equivalents.
• Touch targets are large enough and spaced to reduce accidental activation.
• Hover content can be dismissed, reached, and kept visible when needed.

Language and cognition

• Page language and language changes are identified in code.
• Instructions avoid unnecessary jargon.
• Layout and labels remain consistent.
• Dense material is divided with useful headings and summaries.
• Authentication should not rely on memory puzzles when accessible alternatives exist.
• Help appears consistently where the task needs it.

Third-party services

Some sites depend on scheduling tools, maps, review widgets, payment services, video players, chat tools, or practice-management platforms controlled by other companies. We evaluate these integrations and seek accessible configurations or alternatives.

We do not pretend ownership where we do not have it. If a third-party barrier cannot be fixed directly, we document it, provide an alternate path where practical, raise the issue with the provider, and help the client assess replacement options.

Overlays are not our accessibility strategy

UserDent does not treat a one-line accessibility overlay or toolbar as a substitute for accessible design and code.

Personalization controls can be useful when thoughtfully implemented. They do not repair missing labels, broken keyboard behavior, incorrect semantics, unusable focus order, inaccessible documents, or confusing content at their source. Accessibility must live in the product itself.

Our relationship with LoveA11y

We display the LoveA11y identity because its message matches our own: accessibility deserves a visible culture of empathy and inclusion.

LoveA11y is a free identity created for people who support accessibility. Its mark combines love with “a11y,” the common shorthand for accessibility, and is released trademark- and copyright-free for the world to use.[3]

Using the mark does not certify conformance. It states where we stand. The proof must still be present in the work.

Feedback and barrier reporting

If any part of UserDent’s website is difficult or impossible to use, tell us. Reports are welcome from disabled people, caregivers, advocates, clients, testers, and anyone who encounters a barrier.

Email support@userdent.com and, if possible, include:

• the page URL;
• what you were trying to do;
• what happened;
• browser and device;
• assistive technology, if relevant and if you choose to share it;
• a screenshot or recording, if convenient;
• your preferred way to receive a response.

You do not need to prove a disability or cite a WCAG success criterion. A description of the problem is enough.

We aim to acknowledge accessibility feedback within 2 business days. Resolution time depends on severity, technical complexity, and third-party dependencies. Critical blockers to essential tasks receive priority. When an immediate repair is not possible, we will try to provide an accessible alternative and communicate progress.

Compatibility and limitations

We design for current versions of major browsers and common assistive technologies. Exact behavior can vary across operating systems, browser engines, screen readers, zoom tools, voice-control tools, and user settings.

No website remains accessible through intent alone. Content and technology change. This statement describes our process and target, not a claim that no barrier can ever exist. If our testing misses something, we want to know and fix it.

Useful accessibility resources

• WCAG 2.2 standard
• Understanding WCAG 2.2
• W3C conformance evaluation guidance
• Google Accessibility, which describes building accessible technology with and for disabled people and frames accessibility as a shared responsibility.[4]
• The A11Y Project, a community-driven accessibility resource
• LoveA11y

Sources

1. W3C WAI — Understanding Conformance
2. W3C — Web Content Accessibility Guidelines (WCAG) 2.2
3. Silktide — LoveA11y
4. Google Accessibility — Making Technology for Everyone