This document is in beta. Help us by reporting issues via Github or email
Back to the overview page
Consistent feature names
On this page:
Summary
If a user interface component exists on multiple pages, make sure that the way it looks and the way it is named is consistent across pages.
Requirements
- When the same user interface components, with the same functionality, are used in multiple places, they must be identified in a consistent way. For example:
- An icon has the same alternative text wherever it is used;
- Buttons for “Next”, “Previous”, and “Continue”, are labelled consistently wherever they are used;
- Form fields with the same purpose are consistently labelled wherever they are used.
- Navigational items that are repeated on multiple pages (e.g. Search field, social media links, related links panels) are labelled consistently across the website/app.
Common mistakes
- An icon is used to denote a file download, but has a different alternate text whenever it is used;
- A search facility is provided on every page, but the text field and button have different labels on each page.
Why?
- This helps screen reader users correctly identify the type and purpose of the features that are present on multiple pages/screens.
- It also helps speech-input users know what to say to activate functionalities, based on what worked on other pages/screens.
Official wording in the Web Content Accessibility Guidelines
3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)
This applies to native apps by replacing “Web pages” with “screens”.
See the W3C’s detailed explanation of this guideline with techniques and examples.
Guidance for Design
Visible labels
- If you repeat a button with the same functionality across pages, makes sure that the button’s label is always the same.
Accessibility Name
- On your designs, specify what the ‘Accessible Name’ of each interactive component should be. This ensures that developers identify user interface components consistently to screen reader and speech-input users.
More info
Sources
Contribute
This document is in beta. Help us by reporting issues via Github or email