Accessible Patient Portal Design: Building WCAG 2.2 AA In From the Start

A portal has a different accessibility risk profile from a public healthcare website because authentication controls access to everything behind the login.

The public website may provide information about services, locations, and contact routes. A portal may contain medication information, laboratory results, appointment details, clinical documents, messages, and other patient-specific information.

That makes the authentication journey a critical accessibility boundary. If the patient cannot complete that journey, accessibility behind the login becomes irrelevant to that patient.

For teams defining a new build, accessibility requirements should sit alongside authentication, security, identity management, and clinical workflow requirements. This is also where your patient portal development requirement should explicitly include accessibility acceptance criteria.

Accessibility audits often begin by reviewing pages that are already accessible to the tester.

That approach can miss the most important barrier in a portal. A keyboard user may encounter a focus trap, an inaccessible verification step, or an authentication control that cannot be completed without a mouse.

The issue becomes more significant when authentication involves multiple interface states. Login errors, password recovery, verification codes, MFA prompts, and expired sessions all need a defined keyboard and screen reader behaviour.

While building patient portals, we have tested login flows with keyboard-only users before development began. That approach identified a focus trap early, before it could block every keyboard-dependent patient.

Your specification should therefore define accessibility requirements for every authentication state, not just the initial login screen.

The AudioEye Digital Accessibility Index 2025 reports an average of 6.1 keyboard accessibility violations per healthcare web page.

That figure is not a patient portal-specific failure rate. It does, however, illustrate why keyboard operability deserves explicit attention during portal planning.

Common problems include:

Testing should cover the complete authentication journey from the first field through successful entry into the authenticated application.

WCAG 2.2 introduced Accessible Authentication through Success Criterion 3.3.8.

The requirement matters because authentication can require cognitive functions that create barriers for some users. Patient portals should therefore avoid making successful authentication dependent on a single interaction that some users cannot complete.

Your wider WCAG 2.2 AA compliance for healthcare requirements should define how authentication works across the portal, including password entry, password recovery, MFA, verification, and related error states.

Accessible Authentication addresses situations where authentication requires a cognitive function test.

A memorised password can be necessary for authentication, but the surrounding process should not introduce avoidable barriers. WCAG 2.2 provides exceptions and permitted approaches, so your implementation needs to assess the actual authentication mechanism rather than applying a simplified rule.

For a patient portal, this means reviewing the entire authentication flow rather than checking only whether a password field has a visible label.

Consider the complete sequence:

The specification should document the expected behaviour for each state.

Custom authentication interfaces can introduce accessibility problems when developers replace standard controls with highly customised components.

A visually polished login screen may still create problems if focus indicators disappear, labels are not programmatically associated, error messages are not exposed to assistive technology, or keyboard users cannot reach a required control.

Accessible alternatives usually start with simpler interaction patterns. Native form controls, clear labels, predictable focus movement, programmatically exposed errors, and properly managed focus states reduce unnecessary complexity.

ARIA can support custom components, but it should not replace accessible HTML when standard controls already provide the required behaviour.

Testing should include JAWS, NVDA, and VoiceOver where appropriate for the portal's target environments. The goal is to verify that patients can understand what the interface is asking them to do and complete the task without relying on visual cues alone.

MFA adds another accessibility consideration because the patient must complete an additional authentication step.

A secure MFA process still needs to be operable with assistive technology. The interaction should not force users into a single inaccessible method when an accessible alternative can be provided.

For example, an implementation may provide an authenticator app alongside SMS rather than making one interaction the only route into the portal.

The security architecture should define the permitted methods, while the accessibility specification defines how each method is presented and completed.

Session timeouts exist for security reasons, particularly when authenticated applications handle Protected Health Information.

The accessibility issue appears when a warning gives the user too little time to understand the message, reach the control, or extend the session.

A timeout mechanism should therefore be treated as part of the interaction design, not simply as a security configuration.

A timeout modal can appear accessible while still preventing some patients from extending their session.

Common failures include focus remaining behind the modal, keyboard users being unable to reach the extension control, or the warning disappearing before the user can respond.

Switch users and people with motor disabilities may also require more time to navigate to the required action.

The implementation should define where focus moves when the warning appears, how users reach the available actions, and what happens when the warning expires.

Our breakdown of the new WCAG 2.2 success criteria provides broader context for the newer WCAG requirements that affect interactive healthcare interfaces.

A practical timeout specification should define:

The exact implementation will depend on the portal architecture and security model.

Accessibility testing should verify both the normal warning state and the expired-session state. Patients should not lose context unnecessarily after an expiry.

Security requirements should not automatically override accessibility considerations.

Instead, the security and accessibility requirements should be specified together. Your team can then determine how the timeout, warning period, extension mechanism, and reauthentication process interact.

Herexa Health included secure session handling as part of its telehealth platform architecture. That type of early architectural decision matters because session behaviour affects both security and patient usability.

Clinical information creates a different accessibility challenge from ordinary website content.

Medication lists, laboratory results, appointment information, and clinical documents often contain dense relationships between labels, values, units, dates, and status indicators.

A screen reader user needs those relationships exposed through the underlying structure, not recreated through visual positioning.

Medication tables should expose relationships between headers and their corresponding data cells.

A patient may need to understand a medication name alongside dosage, frequency, timing, and other relevant information. If those relationships are visually obvious but not programmatically available, screen reader users can receive fragmented information.

During healthcare implementations, we have restructured medication table header associations so screen reader users could correctly match each drug with its dosage and timing.

The specification should therefore identify clinical tables as a distinct accessibility requirement. Developers should know which headers apply to which cells before implementation begins.

Laboratory results often combine a measured value with a unit, reference range, date, and visual status.

That information needs to remain understandable when colour, layout, or visual indicators are removed.

For example, an abnormal result should communicate its status through text or an accessible equivalent. The patient should not need to infer meaning from a coloured indicator alone.

The AudioEye Digital Accessibility Index 2025 reports that healthcare web pages average 69.1 unique colour contrast violations per page. This figure reinforces the need to treat clinical data presentation as an accessibility requirement, not simply a visual design choice.

Colour can support clinical data interpretation, but it should not carry the entire meaning.

A red result indicator may appear obvious to a sighted user. A patient using a screen reader may receive no equivalent information unless the status is also exposed through text or an appropriate accessible name.

The same principle applies to medication warnings, appointment statuses, document states, and other patient-specific information.

Your design system should therefore define accessible status patterns before clinical components are reused across the portal.

File upload is often treated as a small interface component.

Within a patient portal, however, it can support important workflows such as submitting requested documents, forms, identification, or other healthcare information.

The interaction therefore needs keyboard access, clear feedback, and meaningful error handling.

Drag and drop can be convenient for users who can operate a mouse.

It cannot become the only way to submit a document. The same upload function should remain available through a keyboard-operable control that assistive technology can identify and operate.

Screen reader users also need a meaningful name for the upload control and instructions that explain accepted file types or relevant restrictions.

The design should distinguish between the visual drop zone and the actual interactive upload control. That separation makes the underlying interaction easier to test and maintain.

Uploading a document creates several states that need accessible feedback.

Patients need to know when an upload starts, whether it is still processing, whether it succeeded, and whether an error occurred.

A visual progress bar alone may not communicate those changes to a screen reader user. Status messages should therefore be exposed through appropriate accessibility semantics.

Across recent compliance projects, we have specified accessible file upload patterns with clear status announcements before document submission features reached development.

That approach lets developers build the required feedback into the component instead of adding it after testing identifies the problem.

Upload errors should tell the patient what happened and what action is possible.

A generic message such as "Upload failed" may not provide enough information. The interface should communicate the relevant issue and preserve the patient's ability to retry without unnecessary repetition.

Error handling also needs keyboard access and appropriate focus behaviour. If the error appears visually at the top of the page while focus remains elsewhere, the patient may never understand why the submission did not complete.

Your specification should define successful, processing, rejected, and failed states before the component enters development.

Our comparison of patient portals and standard websites also provides useful context when deciding which portal interactions require authenticated, patient-specific workflows.

Accessibility belongs in the patient portal specification because it affects how core workflows are designed.

Authentication, clinical data, session management, document submission, and error handling all depend on technical decisions that become harder to change once the application is established.

Accessibility also has a direct relationship with patient engagement. WebAIM's research on digital accessibility in healthcare reports that accessibility-compliant healthcare websites experience 19% higher patient engagement compared with non-compliant sites.

The figure comes from WebAIM's analysis and should not be treated as a guaranteed outcome for an individual portal. It does, however, provide a useful commercial reason to treat accessibility as part of patient experience.

The most damaging failures are often not isolated cosmetic issues.

A portal can contain accessible content while making essential tasks difficult or impossible. A patient may read clinical information successfully but fail to log in, extend a session, upload a document, or understand a laboratory result.

These failures are particularly important for healthcare organisations because the portal often becomes part of an ongoing patient journey.

Testing therefore needs to follow realistic workflows rather than only reviewing individual components.

A useful test journey might include:

That sequence provides more meaningful evidence than checking isolated pages without considering how patients actually use the portal.

Accessibility requirements influence component architecture, design systems, interaction patterns, testing methods, and acceptance criteria.

If those requirements appear only after development, remediation may affect several connected components rather than one screen.

The specification should therefore state the required WCAG 2.2 AA behaviour for high-risk workflows before development begins.

Include acceptance criteria for authentication, session management, clinical data, file upload, error handling, keyboard navigation, focus management, and screen reader compatibility.

Qrolic Health works on healthcare platforms where these requirements are considered alongside clinical workflows and technical architecture. For teams preparing a patient portal specification, that means accessibility can be addressed before implementation decisions become difficult to change.

For broader requirements, refer to our complete WCAG 2.2 AA guide for healthcare when defining the accessibility baseline for your portal project.

Accessible patient portal design should begin with the specification, not the final accessibility audit.

Authentication, session timeouts, clinical tables, file uploads, and error states all create accessibility requirements that affect architecture and component design. Treating these areas as acceptance criteria gives your development team clearer technical direction.

WCAG 2.2 AA also requires more than visual inspection. Keyboard interaction, focus behaviour, semantic structure, status communication, and assistive technology support need practical testing across realistic patient journeys.

For healthcare IT leaders, the key question is therefore not whether accessibility will be tested. It is whether the portal has been specified so accessibility can be built into every critical workflow from the start.

A patient portal that fails at login fails every patient behind it.