A component can work well in isolation and still create accessibility barriers when it becomes part of a larger interface. Its labels may lose their meaning, its headings may no longer fit, or its focus behavior may conflict with another component’s behavior.
Component accessibility does not automatically establish interface accessibility. A component provides part of an experience. People use the relationships between those parts to understand information, move through a task, recover from errors, and recognize completion.
This does not make component-level testing less valuable. It means that accessibility also needs to be reviewed where components meet—and where their surrounding context changes.
Accessibility Depends on Context
A component test can establish useful facts: a button has an accessible name, a dialog contains keyboard focus while open, or a field exposes its instructions and error message. Those findings apply to the implementation and conditions tested.
Assembly introduces additional conditions. The button now appears beside several similar buttons. The dialog opens from a temporary menu. The field becomes one of several repeated address groups. Each change can affect whether the original implementation remains understandable and usable.
It helps to distinguish three levels of review:
- Component behavior: Does this part expose appropriate semantics and support its intended interactions?
- Composition: Do the parts preserve meaningful relationships and coordinate their behavior?
- Task completion: Can someone use the assembled interface to achieve the intended result?
The middle level is easy to miss. A collection of individually reasonable components can still produce an interface with competing focus changes, unclear relationships, or contradictory feedback.
Reusable website components help preserve consistent implementations. Composition review checks whether those implementations still fit the places where they are used.
Names, Headings, and Landmarks Can Lose Meaning
Names and structural elements describe relationships, not just individual objects. Their usefulness depends partly on what surrounds them.
Repeated controls may need more specific context
A standalone card with an “Edit” button may be clear. A page containing billing details, shipping details, contact preferences, and several saved addresses may contain many “Edit” buttons.
Repeated names are not automatically an accessibility failure. The question is whether people can determine what each control affects through accessible context. Visual proximity alone may not provide that relationship to someone navigating controls with a screen reader or selecting them by voice.
Where the target would otherwise be unclear, visible labels such as “Edit billing address” and “Edit shipping address” can help everyone. If a shorter visible label is necessary, an accessible name can add context while retaining the visible wording.
The goal is not to make every name unique at any cost. It is to make each action understandable in its actual setting. The distinction between visible labels and accessible names is explored further in links and buttons.
Heading levels belong to the surrounding document
A card heading marked as <h2> may fit directly beneath a page title. Place that same card inside a subsection, and the appropriate heading level may change.
A component that hard-codes its heading level can therefore impose an unintended outline on the page. Conversely, removing heading semantics to avoid the problem can make the content harder to navigate.
A more durable approach separates heading appearance from heading level and lets the integrating page supply the appropriate structure. The review question is whether the headings accurately describe the relationships among sections—not merely whether their visual sizes look consistent.
Landmarks need page-level judgment
Not every reusable content block needs to create a landmark. A component that always includes <main>, for example, can conflict with the page’s existing main content region.
Other elements depend on context. A <header> inside an article does not have the same landmark role as a page-level header. Several navigation regions may be appropriate, but distinct navigation purposes should be distinguishable through useful names.
Review the assembled page’s landmark structure rather than assuming that more semantic containers produce better navigation. HTML landmarks should identify meaningful page regions, not simply repeat component boundaries.
Repeated instances must preserve their own associations
A form component may correctly connect a label, input, hint, and error message in its demonstration. If every instance reuses the same IDs, those relationships can break when the component appears twice.
Each instance needs unique identifiers and matching references. This includes relationships created through for, aria-labelledby, aria-describedby, and other ID-based attributes. Labels that look correct on screen are not enough to establish that the intended associations survived assembly.
Focus Can Break Between Components
Focus problems often occur during transitions rather than within a component’s steady state. Opening, closing, replacing, and removing interface elements can expose assumptions that an isolated test never reaches.
A dialog may outlive its trigger
Consider an “Edit address” command inside an overflow menu. Activating it closes the menu and opens a dialog. The menu component may try to return focus to its menu button while the dialog component tries to move focus into the dialog.
Both behaviors can be reasonable separately. Together, they may compete.
Closing the dialog introduces another question: where should focus return if the original menu item no longer exists? Attempting to focus a removed element does not provide a usable return path.
The integrated behavior needs to establish:
- Which component owns focus during the transition.
- When the dialog is ready to receive focus.
- Which stable control is the appropriate return destination.
- What should happen if the completed action removes or replaces that destination.
The correct destination depends on the task. It might be the overflow-menu button, the next available item after a deletion, or another logical point in the workflow. Returning to the original trigger is a useful default, not an unconditional rule.
Page updates can interfere with local interactions
A filter panel may preserve focus correctly while a results component replaces content. But if the replacement also removes the active control, or if a page-level update routine moves focus elsewhere, the combined experience may become disorienting.
This is why focus management needs coordination across boundaries. A component should not move focus merely because it has finished updating. Focus movement should support the person’s current action and the resulting interface state.
Errors and Announcements Need Coordination
Feedback components can be accessible individually while producing confusing output together. The problem may be duplication, missing relationships, contradictory state, or poor timing.
Error summaries and field errors must describe the same state
An error-summary component can provide clear text and keyboard-accessible links. Individual fields can expose their own errors correctly. The assembled form can still fail if a summary link targets the wrong instance, points to a field inside a closed section, or remains after the error has been corrected.
The relationship needs to work in both directions:
- The summary identifies the current problem and helps the person reach it.
- The destination exposes the relevant field, instructions, and error.
- Corrections update both the field state and the summary.
- Any focus movement follows a deliberate form-level strategy.
For example, a link to an invalid field inside a collapsed panel may need to reveal the panel before focusing the field. Neither the summary component nor the field component can guarantee that behavior alone.
Multiple live regions can compete for attention
A save action might activate a button status, a form message, a global notification, and a background synchronization message. If each component independently announces its update, one action can generate several overlapping or repetitive announcements.
Exact announcement behavior varies across browsers and assistive technologies, but duplicated ownership remains a design problem.
Decide which part of the interface communicates progress, which communicates the result, and whether other visible updates need announcements at all. Routine progress should not automatically be treated as an urgent alert.
Messages must also agree about what happened. A local “Saved” notification and a page-level “Unsaved changes” warning should not remain simultaneously active unless they refer to clearly distinguished information. Coordinated interface feedback communicates the actual state of the task, not merely the local state of each component.
Responsive Layouts Can Change Relationships
Components may each adapt successfully to a narrow container while the surrounding layout changes their reading or interaction order in an unhelpful way.
For example, a checkout layout might visually place delivery instructions before the address fields while leaving those instructions after the fields in document order. A keyboard or screen-reader user may encounter the task differently from someone following the visual arrangement.
Different visual and source orders are not automatically wrong. They become a problem when the difference disrupts meaning, instructions, or operation. Review source order and visual order as relationships across the whole interface.
Composition can also introduce physical interference. A sticky summary panel may cover a focused control at high zoom, even though the panel and control each passed their own tests. An error message may expand one component and push an important action beneath a fixed toolbar.
Responsive accessibility therefore includes how parts share space, not just whether each part fits inside its own box.
Define Responsibilities at Component Boundaries
Components do not need to understand every possible page where they might appear. They do need clear assumptions, configurable relationships, and limits on the behavior they control.
Useful integration responsibilities include:
- Naming: Who supplies the context needed to distinguish a control’s target?
- Document structure: Who chooses heading levels and landmark placement?
- Associations: How are unique IDs and their references generated?
- Focus: Who controls entry, return, removal, and transition behavior?
- Feedback: Which component owns each announcement or status message?
- State: What shared state keeps summaries, fields, controls, and notifications consistent?
These responsibilities can be recorded in component documentation and supported through implementation choices. A dialog might accept an explicit return-focus destination. A card might accept a heading level. A form might manage error-summary relationships centrally rather than leaving each field to invent them.
This is not a demand for elaborate configuration everywhere. It is a way to avoid hidden assumptions where context genuinely changes behavior.
Review the Composed Interface
Composition review should concentrate on the boundaries most likely to introduce new behavior. Repeating every component test is less useful than checking what assembly has changed.
- Repeat components. Check whether names remain understandable and identifiers remain unique.
- Inspect the page structure. Review headings, landmarks, grouping, and reading order in their final context.
- Follow transitions. Open, close, replace, and remove elements while observing where focus goes.
- Create combined states. Test validation errors, loading, expanded sections, notifications, and updated content together.
- Change the available space. Check zoom and narrow layouts for obscured controls, broken relationships, and confusing sequences.
- Complete the task. Continue through correction and confirmation rather than stopping when each control responds.
Automated checks can identify some structural problems, including certain invalid relationships and duplicate IDs. They cannot establish whether a return-focus destination makes sense or whether several individually valid messages form a coherent explanation. Those questions require interaction and judgment, including testing complete tasks with assistive technology.
When a composition problem is fixed, preserve a regression example that includes the relationship that failed. A dialog launched from a temporary menu should remain a test case; testing only the dialog’s ordinary launch button would miss the original issue.
Accessible components provide a strong foundation. An accessible interface also needs clear relationships between those components: names that retain context, structure that remains meaningful, focus that follows the task, and feedback that describes a consistent state. Those relationships become visible only when the parts are used together.