Back to index

Inclusive Design Patterns

Tags: #design #technology #web development #accessibility #usability

Authors: Heydon Pickering

Overview

As a web designer, I’ve come to realize that building inclusive interfaces is not just the right thing to do ethically, it also results in more robust and user-friendly designs for everyone. This book aims to guide you through the process of creating web interfaces that are accessible to a wide range of users, regardless of their abilities, preferences, or circumstances. We’ll explore common interface patterns like navigation menus, filter widgets, and registration forms, examining how to implement them in a way that is both functional and inclusive. My approach emphasizes the use of semantic HTML, CSS for progressive enhancement, and thoughtful JavaScript where necessary. This book is not just about meeting accessibility guidelines, it’s about understanding how people actually use the web and designing experiences that are enjoyable and effective for everyone. By embracing inclusivity as a core design principle, we can create a web that is truly accessible and empowering for all. This book is written for designers and developers who want to create better web experiences, free from the burden of fixing avoidable mistakes.

Book Outline

1. Introduction

This chapter introduces the concept of inclusive design and uses the analogy of building robust data structures to illustrate how designing for a variety of needs and circumstances leads to better design overall. This inclusivity is not just an ethical concern but a practical one: a website that works well for someone with disabilities, for example, will often work better for everyone. The chapter concludes with a simple example of an inclusive button design, contrasting it with approaches that would exclude certain users.

Key concept: Where people differ — and they always do — inclusive interfaces are robust interfaces.

2. The Document

This chapter focuses on setting up the basic HTML document for inclusive design. It covers the importance of the doctype declaration for ensuring proper rendering, the lang attribute for communicating the language of the content to browsers and assistive technologies, and the fundamentals of responsive design, including content breakpoints and allowing pinch-to-zoom.

Key concept: Your interface is not the only interface users are interacting with when their browsers are open.

3. A Paragraph

This chapter delves into the design of paragraphs for accessibility and readability. It covers choosing appropriate typefaces for users with dyslexia and other reading challenges, using relative units for font size and line height to allow for user customization, ensuring sufficient color contrast, and styling links for both visual and non-visual users. The chapter also emphasizes the importance of content-first design, arguing that the writing itself should be considered a design activity.

Key concept: “Never send a picture to do the job of words.”

4. A Blog Post

Building on the previous chapter, this chapter examines the design of a blog post as a practical application of inclusive paragraph design principles. It covers using semantic HTML for headings and sections to create a logical structure, incorporating video content with transcripts and captions, and establishing a CSS flow system that ensures a consistent and readable layout even with varying content lengths.

Key concept: Everything but content is an enhancement.

5. Evaluation By Pattern

This chapter steps back from specific design patterns to address the broader challenge of evaluating and testing for inclusivity. It argues that reporting accessibility failures by abstract principles, as is common practice, is less actionable for development teams than reporting by pattern. It proposes a points system for evaluating design decisions, awarding higher points for solutions that benefit a wider range of users, regardless of their abilities or circumstances.

Key concept: One hundred points is what we’re aiming for here.

6. Navigation Regions

This chapter focuses on the inclusive design of navigation regions, including both site-wide navigation and in-page tables of contents. It emphasizes the use of lists as a robust and semantically meaningful structure, the importance of clear labels and visual indicators for the current page, and the need to accommodate different screen reader navigation strategies. The chapter also shows how to avoid redundant markup and interactions, making navigation as efficient as possible.

Key concept: Providing unobtrusive options for users is sometimes called multimodality.

7. A Menu Button

This chapter tackles the design of menu buttons, a seemingly simple interface element that presents a number of challenges for inclusivity. It covers the importance of choosing an icon that is widely understood and rendering it in a way that is robust across different user settings and contexts. The chapter also examines how to provide accessible labels for the button, communicate its state non-visually, and ensure that it has a sufficiently large touch target.

Key concept: “Leave creativity to the bad designers. This is not the place to do something different. If a convention exists, use it.”

8. A List Of Products

This chapter explores the design of a product list with inclusivity in mind. It emphasizes the importance of using semantic HTML to structure the list and its items, providing alternative text for images that conveys meaningful information, and optimizing image performance for users on slow networks. The chapter also discusses the use of structured data to enhance the product information in search engine results pages.

Key concept: Everybody is a keyboard user when eating with their mouse hand.

9. A Filter Widget

This chapter looks at the design of a filter widget that allows users to sort and refine a list of products. It demonstrates how to use standard HTML form elements to create the widget, providing keyboard accessibility and screen reader support without relying on JavaScript. The chapter also covers enhancing the widget with JavaScript to provide a smoother user experience, including XHR for dynamic content loading and live regions for providing feedback to screen reader users.

Key concept: In general, it’s better to avoid block-level links like this one. Just because the specification mandates that something is technically valid markup doesn’t mean it produces an agreeable user experience.

10. A Registration Form

This chapter delves into the design of an accessible registration form, focusing on the use of semantic HTML and WAI-ARIA to provide clear labels, error messages, and input assistance. It covers best practices for handling required fields, password inputs, and form validation, emphasizing the importance of providing a consistent and predictable user experience, particularly for screen reader users. The chapter also discusses the use of microcopy to guide the user through the registration process.

Key concept: In summary: never fix with JavaScript and WAI-ARIA what can be achieved with HTML and CSS.

11. Inclusive Prototyping

This chapter introduces the concept of inclusive prototyping, arguing that it’s essential to consider accessibility and usability from the earliest stages of the design process. It focuses on the benefits of paper prototyping as a low-fidelity method for testing and iterating on interface designs, involving a wider range of participants in the design process. The chapter also provides practical guidance on conducting paper prototype testing sessions.

Key concept: In short: HTML on which to stick them. So, you might as well get the HTML right first.

12. Test-Driven Markup

This chapter proposes a novel approach to testing the structure of HTML markup using the logic of CSS selectors. It demonstrates how to write CSS rules that target specific patterns in the markup, highlighting potential errors with visual indicators. The chapter also discusses how to provide informative error messages to developers, using CSS pseudo-content and the developer tools CSS inspector.

Key concept: ERROR: “Only <li> elements are permitted as children of <ul> elements”

13. Further Reading

This chapter provides a curated list of further reading resources for those interested in delving deeper into inclusive design. It includes books, blogs, articles, and other online resources covering a wide range of topics related to accessibility, usability, performance, and internationalization.

Key concept: One of the best things about writing a book about patterns is that there are always more patterns to talk about.

Essential Questions

1. What is Inclusive Design, and why is it important in web development?

Inclusive design is a mindset that prioritizes inclusivity of ability, preference, and circumstance in interface design. It recognizes that people interact with the web in diverse ways and seeks to create experiences that are accessible and enjoyable for everyone, not just the ‘average user.’ This approach involves understanding the needs and limitations of users with disabilities, considering different input methods and devices, and designing for a variety of contexts and environments. Pickering emphasizes that designing for edge cases and extreme scenarios ultimately benefits all users, as robust interfaces tend to be more usable and adaptable overall.

2. Why does the author advocate moving away from print design principles for the web, and what alternative approach does he propose?

Pickering argues that relying solely on visual design principles borrowed from print design can be detrimental to web accessibility. The web is fundamentally different from print in its dynamism, user control, and reliance on code. Inclusive web design requires thinking about how content is structured, how it interacts with assistive technologies, and how it adapts to different devices and user settings. This involves using semantic HTML to create a logical structure, ensuring sufficient color contrast and font readability, and allowing users to customize their viewing experience through features like zoom and text resizing.

3. Why does Pickering champion the use of standard HTML elements over custom JavaScript solutions, and how does this relate to accessibility?

Standard HTML elements often provide built-in accessibility features that are overlooked in favor of custom JavaScript solutions. Pickering champions the use of semantic HTML elements like <button>, <nav>, and <ul> whenever possible, arguing that these elements offer a robust foundation for accessibility and interoperability with assistive technologies. He cautions against over-engineering interfaces with custom JavaScript, especially when standard HTML elements can achieve the same functionality with less code and fewer potential accessibility issues.

4. What is ‘Test-Driven Markup,’ and how does it contribute to inclusive design?

Pickering suggests a ‘test-driven markup’ approach to catch accessibility errors during development. This leverages the logic of CSS selectors to identify patterns in the HTML markup that may pose accessibility issues. These tests can be automated and run alongside traditional code tests to ensure that the structure of the interface conforms to expected patterns and includes necessary accessibility provisions. This approach helps prevent the accumulation of accessibility issues later in the development process, promoting a more proactive and inclusive design workflow.

5. Why does the author advocate for paper prototyping, and how does it support inclusive design practices?

Pickering argues that paper prototyping is an invaluable tool for inclusive design because it allows for a more diverse group of participants to engage in the design process. Stakeholders, users with disabilities, and team members with varying technical skills can all contribute to paper prototypes, fostering a more collaborative and inclusive design approach. The low-fidelity nature of paper prototypes encourages a focus on core functionality and usability, avoiding distractions related to visual aesthetics or implementation details.

Key Takeaways

1. Design for a Diverse Audience

Pickering’s emphasis on inclusivity extends beyond visual design to encompass a wide range of user abilities and preferences. This includes considering users with disabilities, varying levels of technical literacy, and those using different input methods or devices. Designing for a diverse audience requires understanding their unique needs and challenges, testing with real users, and providing options and flexibility in how users interact with the interface.

Practical Application:

In designing a voice assistant, considering the diversity of accents, speech patterns, and language abilities is crucial. The voice assistant should be able to understand and respond accurately to a wide range of users, including those with speech impairments. This can be achieved by training the AI models on diverse datasets and using robust speech recognition algorithms that are tolerant of variations in speech.

2. Embrace Semantic HTML

Pickering emphasizes the use of semantic HTML as the foundation for accessibility. Semantic HTML elements like <button>, <nav>, and <article> provide meaning and structure to the content, making it easier for assistive technologies to understand and interact with the interface. This approach also promotes interoperability, ensuring that the content can be accessed and understood by a variety of devices and platforms.

Practical Application:

Instead of relying solely on visual cues, an AI-powered image recognition system could provide alternative text descriptions of images, making them accessible to blind or low-vision users. These descriptions could also be used to improve search engine optimization and content discovery. This approach enhances the functionality and reach of the AI system, benefiting a wider range of users.

3. Use Clear and Concise Language

Pickering stresses the importance of using clear and concise language, avoiding jargon or unnecessarily complex terms. This is particularly important for instructions, error messages, and other interface elements that guide the user’s interaction with the system. Using plain language enhances comprehension and makes the interface more accessible to users with cognitive disabilities or limited technical literacy.

Practical Application:

When developing an AI-powered chatbot, providing clear and concise instructions and error messages is essential. Instead of using technical jargon or overly complex language, the chatbot should communicate with users in a way that is easy to understand, regardless of their technical background. This improves the usability and effectiveness of the chatbot, making it more accessible to a wider range of users.

4. Test for Accessibility

Testing for accessibility is not just about checking for compliance, it’s about ensuring that the interface is actually usable and enjoyable for everyone. Pickering emphasizes the importance of user testing with diverse participants, including users with disabilities, to identify potential usability issues and gather feedback. He also suggests using automated accessibility testing tools as a first line of defense to catch common errors.

Practical Application:

AI product engineers can incorporate accessibility testing into their development workflow, using automated tools like aXe or Tenon to identify potential issues early on. They can also conduct user testing with diverse participants, including users with disabilities, to gather feedback and identify areas for improvement. This iterative approach ensures that accessibility is considered throughout the product development lifecycle.

5. Prototype for Usability

Pickering advocates for a prototyping-first approach to design, particularly using paper prototypes, to identify usability issues early in the process. This allows for quick and inexpensive iteration, involving users in the design process, and gathering feedback before committing to high-fidelity mockups or code. This user-centered approach helps ensure that the design is truly inclusive and meets the needs of a diverse audience.

Practical Application:

AI product engineers can use low-fidelity prototypes, like wireframes or sketches, to test core functionality and user flows without being bogged down by visual details. This allows for rapid iteration and gathering user feedback early on, ensuring that the product is usable and meets user needs before investing in high-fidelity designs or complex implementations.

Suggested Deep Dive

Chapter: Test-Driven Markup

This chapter’s concept of using CSS selectors for structural testing could be particularly relevant for an AI product engineer. Automating these tests could help ensure that AI-generated markup conforms to expected accessibility patterns, reducing the risk of unintended exclusionary designs.

Memorable Quotes

Inclusive Design. 15

“Never send a picture to do the job of words.”

Progressive Enhancement. 36

“Everything but content is an enhancement.”

APPEARANCE AND PLACEMENT. 133

In other words, we don’t make them think.

Rendering the Icon. 162

“Leave creativity to the bad designers. This is not the place to do something different. If a convention exists, use it.”

In general, it’s better to avoid block-level links like this one. Just because the specification mandates that something is technically valid markup doesn’t mean it produces an agreeable user experience.

Comparative Analysis

While numerous books address web design, “Inclusive Design Patterns” stands out for its unwavering commitment to accessibility and its practical, code-driven approach. Unlike broader web design guides like Zeldman’s “Designing with Web Standards,” Pickering’s work delves specifically into the nuances of crafting interfaces that cater to a diverse range of users. This echoes the spirit of “A Web for Everyone” by Horton and Quesenbery, but with a sharper focus on implementation. Pickering’s emphasis on using semantic HTML as the foundation for accessibility aligns with advocates like Karl Groves, who criticizes the limitations of compliance-driven design. While “Adaptive Web Design” by Gustafson explores the technical aspects of responsive design, Pickering connects it directly to inclusive design, highlighting the interconnectedness of these principles.

Reflection

“Inclusive Design Patterns” is a valuable resource for anyone involved in web design or development, particularly those working with AI and technology. Pickering’s insightful exploration of accessibility and usability provides a framework for creating digital products that are not only technically sound but also genuinely inclusive. The book’s strength lies in its practical, code-driven approach, offering clear examples and actionable solutions for common interface challenges. However, its focus on specific HTML, CSS, and JavaScript techniques may limit its long-term relevance in the ever-evolving landscape of web technologies. Additionally, the author’s strong opinions on certain practices, while well-founded, may not always align with the constraints or priorities of every project. Despite these minor limitations, Pickering’s work serves as a crucial reminder that inclusivity should be a core design principle, not an afterthought. His emphasis on understanding user needs, embracing standards, and testing for accessibility is essential for crafting digital experiences that are truly empowering and accessible to everyone. In the context of AI and technology, where interfaces are becoming increasingly complex and personalized, Pickering’s principles are more relevant than ever, offering a foundation for building AI systems that are both intelligent and inclusive.

Flashcards

What is inclusive design?

The principle of designing for a variety of needs and circumstances, recognizing that people interact with the web in diverse ways.

What are the advantages of using unordered lists (<ul>) for navigation?

A robust and semantically meaningful structure for navigation regions, offering advantages for accessibility and progressive enhancement.

Why is using relative units (like rem or em) for font sizes important for accessibility?

It allows users to customize font size without breaking the layout, improving readability.

What is background-size?

A CSS property that allows you to scale background images, making them more adaptable to different screen sizes.

What does .visually-hidden do?

A screen reader accessible hiding technique that visually hides content while keeping it available to assistive technologies.

What is aria-expanded?

A WAI-ARIA attribute that indicates whether an element is expanded or collapsed, often used for menus and accordions.

What is the importance of non-blocking asset loading (like for web fonts)?

Ensures that the page content arrives as quickly as possible, even on slow networks.

What is the “Load more” button pattern?

A method for progressively loading more content as the user scrolls, avoiding the usability issues of infinite scroll.

What is the purpose of a <fieldset> and <legend>?

A method for grouping related form fields and providing a label for the group.

What is aria-required?

A WAI-ARIA attribute that indicates whether a form field is required.