User experience

Accessibility originates with UX design. Accessibility requirements should be considered, clarified and communicated before the first line of code is written. Often when something is broken or hard to make accessible it's because the UX design doesn't quite work for all users and has a knock on affect of breaking content for disabled users. These standards and guidelines should be used to form the basis of the accessibility requirements that can be applied to a project.

Ideally wireframes should be annotated to include a structural outline, interactions and behaviour while UX should clarify colour contrast, provide alternatives for colour and meaning, and clarify hover, focus, selected and touch states (amongst other things).

Working in an agile environment it is likely that overall requirements and visual design will evolve. That's expected but by having the foundation for accessibility documented from the outset the product becomes less susceptible to embedding barriers to access further down the line and accessibility, if done well, has the potential to help innovate a product.

The BBC Global Experience Language includes a good introduction on how to design for accessibility. You may also wish to refer to the BBC Editorial Guidelines.



The foundation principles of these guidelines require using standard controls where possible, as intended, and supporting the native accessibility features of a platform.

Where possible include standard interface controls in designs rather than custom built controls. These are familiar to users and usually come with accessibility built in. For example a standard iOS UI component for a 'slider' used for volume control will come with a hint to let VoiceOver users know how to use it and is a familiar design pattern used in other apps.

If custom components are used research how similar standard UI components have accessibility built in and mimic this as far as possible. You can do this by using VoiceOver to test apps that come bundled with iOS.


Audio and Video - The media player is handled by the Media Playout and AV Key Experience teams at BBC. If you need to design a media player or are creating interactive content, consider font size, style and position of controls, and how content is presented. If there is a strong reason why content should autoplay, ensure the user is aware this will happen and can set preferences to prevent it.

Design - User experience designers are responsible for all design considerations and should annotate wireframes and design documents appropriately. This includes clarity on colour contrast, colour and meaning, touch target sizes, content resizing, actionable elements, and visible focus, and consideration around content consistency and adjustability.

Editorial - Use consistent labelling for buttons, links and headings. Work closely with editorial colleagues to maintain consistency.

Focus - The way in which content is presented visually can impact the order in which content is coded and subsequently the content order and focus order in which a user experiences the content, particularly users with alternative input methods such as keyboard or screen reader users.

Forms - Provide labels for all form inputs, and ensure form layout and order is clear i.e. related form inputs can follow each other in the content order and if necessary visual design is applied to imply grouping.

Images - If possible avoid images of text and don't convey key information solely through a background image.

Links - Design content layouts that facilitate grouping text and images as one link.

Notifications - Design notifications to be inclusive and perceivable by all users. Where appropriate, include other feedback and assistance cues and prompts that might guide or encourage a user when needed.

Scripts and dynamic content - Work from a basic core experience and progressively enhance this for more capable users.

Structure - It is essential that design documents conveys the intended structure of content. Identify headings, containers and landmarks, working closely with developer colleagues if needed.