We will look at an interactive element, a button, from the perspective of three types of designers. The purpose of this example is to show you how a little bit of knowledge about the medium can lead to a simpler and (therefore) more inclusive solution.

We will look into discrete interface patterns; modules, components, widgets, conventions, whatever-you-want-to-call-thems. It would be foolhardy not to first acknowledge that each will ultimately belong to a web document. HTML pages vary dramatically in shape and size and can include any combination of patterns, but there are a handful of ‘document level’ best practices to which we should adhere. The aim here is not to go in search of the ultimate ‘boilerplate’ but to configure a parent web page to support inclusive design.

We’ll be looking at typefaces, leading, measure, justification, contrast, focus indication and more, to help you design paragraphs suited for a hugely diverse audience. We’ll also tackle specific issues for folks with limited vision, dyslexia, Irlen syndrome, low literacy and limited technical knowledge.

We’ll show how to incorporate accessible landmarks and a sound section structure to make the content more navigable and interoperable to a diversity of users and parsers. This will be bolstered by giving well-written and context independent structural as well asand context independent structural and navigational cues.

We’ll progressively enhance HTML’s primitives to create the inclusive means to navigate within and between web pages. We will also cover design provisions transferable to many other patterns, including logical source order and the virtue of eliminating redundancy. We will also tackle how to progressively enhance the navigation with JavaScript.

In this chapter, we’ll ensure our menu button and the content it reveals are inclusive of differing user settings, circumstances, devices, and assistive technology software.

By going straight from paper to HTML, we lay the foundations for efficient code and inclusive experiences.

In this chapter, we’ll practice our inclusive design chops. As in previous patterns, the organization and structure of content is paramount. We’ll look deeply into image accessibility, from both the perspectives of alternative text composition and performance. In catering to blind consumers, to those who cannot afford generous data contracts, and anyone accessing your content from outside your interface, this is a chance to really push the limits of inclusive design.

We’ll explore the importance of giving users choice and control over how their content is arranged. We’ll also use some techniques to make sure our design was tolerant of dynamic and fluctuating content. Inclusive design also means a visual design which is not too strict about the nature of the content imparted to it.

This chapter will give you everything you need to develop inclusive forms. By using standard form elements, effective labeling and facilitating the correction of errors, users of all walks are able to access and contribute to your websites and apps. By keeping the form simple and avoiding irritating experiences like disappearing labels and passwords that you cannot check, we’ve made sure using the form isn’t just possible but pleasurable.

Test-driven development allows developers working with frequent iterations to move forward with confidence. By writing tests first, to prescribe outcomes, then creating the functionality to achieve them, you can ensure successful builds behave in a predictable and reliable fashion.