惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
Security Latest
Security Latest
C
Cisco Blogs
P
Palo Alto Networks Blog
Know Your Adversary
Know Your Adversary
Project Zero
Project Zero
C
Cyber Attacks, Cyber Crime and Cyber Security
NISL@THU
NISL@THU
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
S
Secure Thoughts
P
Privacy International News Feed
V
Vulnerabilities – Threatpost
D
Docker
Google Online Security Blog
Google Online Security Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
Recent Announcements
Recent Announcements
T
The Exploit Database - CXSecurity.com
G
Google Developers Blog
Schneier on Security
Schneier on Security
小众软件
小众软件
爱范儿
爱范儿
GbyAI
GbyAI
J
Java Code Geeks
T
Tailwind CSS Blog
Cisco Talos Blog
Cisco Talos Blog
The Hacker News
The Hacker News
D
DataBreaches.Net
Blog — PlanetScale
Blog — PlanetScale
TaoSecurity Blog
TaoSecurity Blog
MyScale Blog
MyScale Blog
B
Blog RSS Feed
Cyberwarzone
Cyberwarzone
有赞技术团队
有赞技术团队
Martin Fowler
Martin Fowler
C
CXSECURITY Database RSS Feed - CXSecurity.com
S
Securelist
L
Lohrmann on Cybersecurity
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Y
Y Combinator Blog
S
Schneier on Security
Latest news
Latest news
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 叶小钗
F
Fortinet All Blogs
M
MIT News - Artificial intelligence
PCI Perspectives
PCI Perspectives
V
V2EX
V2EX - 技术
V2EX - 技术
O
OpenAI News
W
WeLiveSecurity

TetraLogical Blog

Designing for people with reading disabilities - TetraLogical Designing for people who are D/deaf - TetraLogical Designing accessible documents - TetraLogical Introduction to creating accessible documents - TetraLogical Inclusive user research: vulnerable people - TetraLogical Designing for people who are blind - TetraLogical Designing for people with low vision - TetraLogical Meet the team: Niamh Madden - TetraLogical Designing for people with anxiety - TetraLogical Designing for people with disabilities - TetraLogical Accessible building blocks for the web videos - TetraLogical Common accessibility misconceptions - TetraLogical Common misconceptions about testing accessibility - TetraLogical Common misconceptions about implementing accessibility - TetraLogical Common misconceptions about WCAG - TetraLogical Common misconceptions about disability - TetraLogical Meet the team: Grace Snow - TetraLogical Sustainable accessibility in complex organisations: strategic foundations - TetraLogical Sustainable accessibility in complex organisations: organisational realities - TetraLogical Sustainable accessibility in complex organisations: external factors - TetraLogical Common misconceptions about screen readers - TetraLogical Guide to the Inclusive Design Principles - TetraLogical Meet the team: Ian Lloyd - TetraLogical Annotating designs using common language - TetraLogical Meet the team: Catriona Morrison - TetraLogical Championing inclusive language - TetraLogical Press release: TetraLogical launches accessible self-led training courses to help digital teams build confidence in accessibility - TetraLogical Why inclusive products are green products - TetraLogical Accessible Recruitment - TetraLogical Accessibility and the agentic web - TetraLogical Meet the team: Craig Abbott - TetraLogical Foundations: types of assistive technology and adaptive strategies - TetraLogical European Accessibility Act (EAA) FAQ - TetraLogical Screen reader HTML support tables - TetraLogical Interview with Lola Odelola - TetraLogical Understanding EN 17161 Design for All - TetraLogical Inclusive user research: building rapport - TetraLogical Foundations: Keyboard accessibility - TetraLogical Can generative AI write contextual text descriptions? - TetraLogical Understanding the European Accessibility Act (EAA) - TetraLogical Meet Josh: a sportsman who has spinal muscular atrophy - TetraLogical Meet Jonathan: a photographer who has ADHD - TetraLogical Foundations: grouping forms with `<fieldset>` and `<legend>` - TetraLogical XR Accessibility: for people with moving disabilities - TetraLogical Meet Andre: a music producer and blind screen reader user - TetraLogical Foundations: types of disability - TetraLogical Meet Lauren: a film editor who has ADHD - TetraLogical Meet Steve: a photographer who is deaf and low vision - TetraLogical Foundations: form validation and error messages - TetraLogical Meet Hasmukh: a blind cricketer and screen reader user - TetraLogical XR Accessibility: for people with hearing disabilities - TetraLogical XR Accessibility: for people with thinking disabilities - TetraLogical XR Accessibility: for people with seeing disabilities - TetraLogical Introduction to XR Accessibility - TetraLogical Foundations: labelling text fields with input and label - TetraLogical Design patterns and WCAG - TetraLogical Does WCAG 2.2 apply to native apps - TetraLogical Why are my live regions not working? - TetraLogical Building a culture of accessibility - TetraLogical When to use tabindex= Accessibility foundations - TetraLogical Meet the team: Demelza Feltham - TetraLogical Can generative AI help write accessible code? - TetraLogical Meet the team: Steve Faulkner - TetraLogical Meet the team: Gez Lemon - TetraLogical Keyboard accessibility myths and WCAG - TetraLogical Amendment to the Public Sector Accessibility Regulations - TetraLogical What Considerations for TV user interface accessibility - TetraLogical Meet the team: Alistair Duggin - TetraLogical Sticky content: focus in view - TetraLogical The only accessibility specialist in the room - TetraLogical Meet the team: Ian Pouncey - TetraLogical Meet the team: Dean Holden - TetraLogical Meeting WCAG Level AAA - TetraLogical Foundations: accessible names and descriptions - TetraLogical Inclusive XR: accessible augmented reality experiences - TetraLogical Foundations: pointer gestures - TetraLogical Meet the team: Graeme Coleman - TetraLogical Adding sign language to videos - TetraLogical Foundations: introduction to WAI-ARIA - TetraLogical Meet the team: Joe Lamyman - TetraLogical Inclusive XR: accessible 3D experiences - TetraLogical Foundations: visible focus styles - TetraLogical Foundations: target sizes - TetraLogical Meet the team: Henny Swan - TetraLogical Meet the team: Ela Gorla - TetraLogical Foundations: native versus custom components - TetraLogical Foundations: HTML semantics - TetraLogical Accessibility and supporting Internet Explorer - TetraLogical Meet the team: Felicity Miners-Jones - TetraLogical Accessibility and QR codes - TetraLogical Inclusive user research: recruiting participants - TetraLogical Research insight: accessibility of images - TetraLogical Meet the team: Léonie Watson - TetraLogical Android accessibility: roles and TalkBack - TetraLogical Meet the team: Patrick H. Lauke - TetraLogical Inclusive user research: analysing findings - TetraLogical How to write user stories for accessibility - TetraLogical Triaging WCAG 2.1 Level AAA - TetraLogical
Accessible design systems - TetraLogical
2022-06-24 · via TetraLogical Blog

Posted on by Henny Swan in Design and development

Tags: Inclusive Design Principles

A design system is a library of styles, components, and patterns used by product teams to consistently and efficiently launch new pages and features. A good system has accessibility embedded throughout and includes documentation, guidelines and implementation notes for accessibility.

Benefits

There are several benefits of an accessible design system for you, your team, your organisation, and the people using your products.

Efficiency

By embedding accessibility in your design system, your team reduces the need to repeat accessibility work, freeing them to focus on new things. For example:

  • Colour pallets don't have to be recreated and tested again and again
  • Visible focus styles can be designed once and used uniformly across a website
  • Text descriptions and accessible names can be written once and used everywhere removing the need to re-write copy

Consistency

As the Inclusive Design Principle, be consistent says:

Use familiar conventions and apply them consistently.

By documenting accessibility for styles, patterns and components, your team reduces the risk of designing and building inconsistent experiences for people with disabilities. For example:

Scale

By increasing accessibility efficiency and consistency, your team can build inclusive products faster and at scale. For example:

  • Complex components such as tab panels, menus and navigation can be built once and re-used across multiple areas of a website or application
  • Accessible styles can be applied across all products and platforms

Usability

By considering accessibility as integral to your design system, you improve the user experience for everyone as many accessibility requirements improve usability for all. For example

  • Good contrast for text and UI components is beneficial for people using a mobile
  • A logical page structure with good use of headings helps everyone understand the relationship between content on a page

Sustainability

By embedding accessibility in a design system, you are one step closer to sustainable accessibility across your products and within your product development process. An accessible design system contributes to:

  • Reducing remediation time for accessibility
  • Creating a culture of accessibility across product teams
  • Freeing up product teams, so accessibility is proactive and not reactive

Contents

Design systems vary, but an accessible design system can include style guides, components, patterns, and accessibility documentation.

Accessibility documentation

Accessibility must be embedded throughout the design system. This means there is general guidance for accessibility and specific accessibility guidance for all styles, components, and patterns.

The general accessibility guidance can include:

  • Your organisation's accessibility principles
  • Your organisation's accessibility compliance level
  • An overview of accessibility guidelines and techniques
  • Accessibility resources for product teams

Specific accessibility documentation is then included with each style, component or pattern.

Visual style guide

A visual style guide documents the look and feel of a brand. What is included can vary but should always include:

  • Colour contrast used for all typography and background colour combinations as well as UI components and meaningful graphical elements so people can perceive a product
  • Visible focus styles for actionable elements including links, buttons, controls and form inputs so people can operate controls
  • Typography with fonts and font sizes that support readability so people can understand a product
  • Icons with visible text labels and text descriptions that help people understand a product
  • Target size for actionable elements so that people with dexterity issues can interact with content
Screenshot of usage guidelines for colour with a warning to not create your own colours
Adobe Spectrum colour usage guidelines document what colour to use and that your own colours should not be used.

Editorial style guide

Editorial guidelines apply to all copy, this includes both visible copy and hidden copy that screen reader users access. It should cover readability and copy patterns for:

An accessible editorial style guide will also document inclusive language guidelines for your organisation. This includes preferred language for:

  • Age
  • Gender
  • Ethnicity
  • Disability
  • Sexual orientation
  • Socio-economic status
A screenshot of the Babylon Health DNA design system editorial guidelines for Being inclusive
The Babylon Health DNA design system included a Writing for people style guide with guidance on being inclusive

Component library

A component library documents re-usable components such as menus, tab panels, accordions, buttons and so on.

Each component is designed, built, and tested for accessibility before it is added to the design system. Each component should include accessibility documentation so designers and developers using the component don't break the accessibility when they add it to a page.

For example, a component should include implementation advice on:

  • Structure
  • Focus order
  • Keyboard behaviour
  • Text descriptions
  • Announced screen reader content
  • Expected user experience

The last item, expected user experience, is a good way of helping people using your design system understand what the expected outcome is for people browsing with different assistive technologies.

The BBC News team have a guide on How to document the screen reader user experience which includes seven steps for designers to consider. There is also an accompanying screen reader UX poster (PDF, 67kb)

Screenshot of the Screen reader UX poster

Pattern library

A pattern library documents how two or more components can be combined to help people complete a task or process. This can be content structure, layouts, page templates, forms, status messages, or other combinations of UI elements.

As with the components, including the expected user experience for people browsing with assistive technologies and various disabilities is key.

Who

An accessible design system is for use by product teams.

Who creates it

When it comes to who is responsible for accessibility in the design system, the short answer is that everyone who works on it is responsible.

If you have a design system team, the team should include at least one person from each discipline. For example a UX researcher, content creator, interaction designer, visual designer, a developer, a QA tester and product owner.

Each team member is responsible for the accessibility of what they design, code, test, or write. This means making the styles, components, and patterns accessible as well as documenting accessibility implementation specifications for each.

How your team manages this process will vary but ultimately, it is a collaborative process. No individual role in the team should work in isolation; multiple roles will have input on what you do:

  • UX researchers are responsible for including people with disabilities in all research, and ensuring accessibility is part of the overall user experience working closely with product owners
  • Content creators are responsible for making sure that all editorial is accessible and work closely with UX researchers, interaction and visual designers
  • Interaction designers are responsible for accessible interactions that support diverse user experiences and will work closely with visual designers and developers
  • Visual designers are responsible for making sure everyone can perceive and understand styles, components, and patterns and work closely with UX researchers, interaction designers and developers
  • Developers are responsible for accessible code working closely with interaction and visual designers
  • Quality Assurance (QA) testers are responsible for verifying the style, component, or pattern meets the expected accessibility standard working closely with developers
  • Product owners are responsible for making sure accessibility is included throughout the design, build and test of assets for the design system working closely with everyone at each stage

If you don't have a design team, you can create your system on a small scale by documenting established accessible style, components and patterns for re-use. This is an investment of time, but it is time you will immediately win back as you evolve your product.

You can also look at adopting or adapting an existing accessible design system, component library, or pattern library. This can be as large or as small as you need:

The Inclusive Components homepage
Inclusive Components by Heydon Pickering documents guidance for 11 common components.

Tip: regardless of whether you are using a third party to host your design system, or you are hosting it on your platform, it must also be accessible.

If using a third party platform, check to see if they have an Accessibility Conformance Report (ACR). You will need to make sure that both the front-end is accessible as well as the back-end so that people with disabilities in your product teams can use and contribute to the design system.

Maintenance

There will be times when product teams can't find the component, style, or pattern they need, or it doesn't do exactly what they need it to do.

When this happens, there is a risk of people adapting styles, creating their own components, or ignoring the design system and doing their own thing. This runs the risk of accessibility becoming compromised or broken.

Put a design system governance process in place where people can request or suggest updates. All new content added to your design system must then pass a design system accessibility assessment before it can be added. All new styles, components, and patterns should meet WCAG 2.1 Level AA and include accessibility implementation guidance, as well as include accessibility documentation.

As well as maintaining accessibility, this has the added benefit of ensuring your design system can evolve and innovate with accessibility being a driver for good.

More information

Next steps

When you want your design system to be the best it can be, our design system accessibility service gives you the information you need to build accessibility into the core of your products and services taking you one big step closer to sustainable accessibility.

Updated 13 January 2023.