Designing for inclusivity

Introduction

In this article, we will be looking over Inclusive design principles, the most common issues faced by users interacting with our designs in terms of accessibility and finally how we can test for accessibility when our designs are in their final stages.

Inclusive design principles

Provide comparable experience

"Ensure your interface provides a comparable experience for all so people can accomplish tasks in a way that suits their needs without undermining the quality of the content. Whether out of circumstance, choice, or context people are diverse. As people use different approaches and tools to read and operate interfaces, what the interface offers each user should be comparable in value, quality, and efficiency." - Inclusive design principles - provide comparable experiences

Consider situation

"People use your interface in different situations. Make sure your interface delivers a valuable experience to people regardless of their circumstances. People are first time users, established users, users at work, users at home, users on the move, and users under pressure. All of these situations can have an impact. For those who already find interaction challenging, such as those with disabilities, this impact may make usage particularly difficult." - Inclusive design principles - consider situation

Be consistent

"Use familiar conventions and apply them consistently. Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behaviour, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way." - Inclusive design principles - be consistent

Give control

"Ensure people are in control. People should be able to access and interact with content in their preferred way. Do not suppress or disable the ability to change standard browser and platform settings such as orientation, font size, zoom, and contrast. In addition, avoid content changes that have not been initiated by the user unless there is a way to control it." - Inclusive design principles - give control

Offer choice

"Consider providing different ways for people to complete tasks, especially those that are complex or non standard. There is often more than one way to complete a task. You cannot assume what someone's preferred way might be. By providing alternatives for layout and task completion, you offer people choices that suit them and their circumstances at the time." - Inclusive design principles - offer choice

Prioritise content

"Help users focus on core tasks, features, and information by prioritising them within the content and layout. Interfaces can be difficult to understand when core features are not clearly exposed and prioritised. A site or application may provide lots of information and functionality, but people should be able to focus on one thing at a time. Identify the core purpose of the interface, and then the content and features needed to fulfil that purpose." - Inclusive design principles - prioritise content

Add value

"Consider the value of features and how they improve the experience for different users. Features should add value to the user experience by providing efficient and diverse ways to find and interact with content. Consider device features such as voice, geolocation, camera and vibration API's, and how integration with connected devices or a second screen could provide choice." - Inclusive design principles - add value

Common issues

Font sizing

Getting down to the crux of what is accepted in the specification of WCAG is difficult and honestly, I haven't really been able to find more than obscure references in the skims over it I have done myself. However, I did find this gem of an article a few years back: What's 'large text' in WCAG 2.0 parlance?

In short, it all boils down to the following:

"For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 18.75px and 24px or 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use." - Steve Faulkner

If we take the example of small text, which is not covered in the above quote but is normally in the user agent style sheet a value of between 80% and 85% of the containing elements font-size. Which if the normal body text has a font-size of 18.75px, we can extrapolate a small text base value of 16px.

Ofcourse, as the article says, no two fonts are wholly equal and this must be taken into account although this is a generally good basis for most fonts overall.

We also need to take the question of responsiveness into question and we will look into adaptive font sizing and scaling in the upcoming development article.

All that is important for this part of the article is to understand how we meet the minimum acceptance criteria for accessible font sizing as outlined above.

Colour contrast

"The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

Large Text

Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

Incidental

Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Logotypes
Text that is part of a logo or brand name has no contrast requirement." - WCAG Success Criterion 1.4.3 - Colour contrast

Using out definitions of normal and large font sizing that we detailed in the Font sizing section of this article, we can now apply the following contrast rules to attain an accessible contrast ratio.

This should be one of the most paramount tests you conduct in the generation or review of any design, if the contrast ratio is too low, certain users won't even be able to perceive your work.

I cannot stress enough how important it is to meet at a minimum the AA standards, especially in regards to contrast ratios.

Provide headers for data tables

Tables are a contentious area in my experience, especially for UI focussed designers who want to make things look good but usually this makes them inaccessible for one person or another. Looking "good" is subjective and if it doesn't provide a comparative experience for all users or fuel understanding, as with all components, it is a failure of design.

The easiest way to solve this issue is to provide appropriate headings for every column at the least and also, where applicable, on each row also.

Another thing to consider is adding a heading for above or a piece of text below to provide extra context on what data is within the table, this is excellent also as developers can then use the <caption></caption> tag which increases the accessibility of the table to a good degree and provides more context of the contents of the table at a glance.

There is an excellent article on creating accessible data tables that goes into great detail on this subject and I highly recommend you give it a read.

Do not rely on colour alone to convey meaning

"The use of colour can enhance comprehension, but do not use colour alone to convey information. Be especially cautious of red/green colour combinations." - Quick Reference Web Accessibility Principles

Lets take the hypothetical stance that we are operating as a data analytics company and as such, we offer dashboards that you can visualise your companies datasets within. Sounds cool, right?

Now say one of our components is this bar chart:

It looks nice, it has correct labelling, each column is a different colour and honestly, it seems to work out of the box right? Well... sadly no is the answer.

The problem here is that for users with colour blindness in one of its forms, this is not a workable solution.

Here is a table of colour blindness types and their associated variations for your reference:

The answer for our case here is to back up our colour based approach with patterns. Patterns help the human eye and brain to do what they do best: Delineate areas of interest and their respective purpose.

For example, here is our previous table but backed up with patterns:

Using this method, we ensure that even without colour, context is provided and the user understands what is what and where without as much reference work required.

Here is a list of bad colour combinations:

• Green & Red
• Green & Brown
• Blue & Purple
• Green & Blue
• Light Green & Yellow
• Blue & Grey
• Green & Grey
• Green & Black

Avoid these, use patterns to reinforce delineation and think about design fundamentals of spacing and unity, these will all help you design better components across the board, colour is merely a foundation to be build upon.

Ensure links make sense out of context

This one is simple and doesn't require as much of a deep dive.

In short: Avoid using text like "click here", "read more", "here", etc.

The text of the link should provide context over WHAT the user is going to see and there assistive technology will tell them the WHERE usually also.

This is something easy and simple to do but with such a small change, it increases understanding, helpfulness and the accessibility of your content.

Button and link states

Lets take an illustrated look through how we might create a button or a link in a design that not only fulfils an expected task but also provides feedback on its current state.

This is something that helps with the perceivable and operable areas of the POUR principles that we outlined in the previous WCAG and WAI-ARIA article.

The default state

This is the default state of a button/link, this would be how a button looks without any form of interaction.

The link state

Link specific: This state is the same as the default state but only applies on links with a valid href. A use case, for example, is that you may want links without a valid href to be styled differently to those that are correctly implemented.

The hover state

This state is triggered when a user hovers a button/link, here we could provide a small piece of visual feedback such as an animation to show the user that their hover action has been applied.

The active state

This state is triggered when a user pressed down on a button/link, here we could also provide a small piece of visual feedback such as an animation in the opposite direction of the hover, to show the user that their click/activate action has been applied.

The focus state

This state is triggered when the button/link is the currently focussed item on the page, this can be achieved by clicking or via keyboard interaction such as using the tab key.

The focus-visible state

This state is triggered when a button/link is the currently focussed item on the page AND the focus was triggered by keyboard input, using the tab key for example.

The disabled state

This state is triggered if the button/link has the disabled attribute applied on it, this would mean the button/link is unable to have any actions run on click but we can still apply other active and hover states on the button/link to provide feedback that the button/link is disabled, should the initial styling not be enough to communicate that.

The visited state

Link specific: This state is triggered when your browser realises you have previously visited the url of the link at hand.

Testing

Testing is as large a part of design as it is development, iteration after iteration, tests of multiple forms are used. From usability testing to A/B testing, but how can we make our tests more inclusive?

Well, for me, the most important point or test to include users of varying abilities is the user testing stage. I think that if you take a step back and think about what your goals are, what the primary actions on your site are and correlate that to one of the main disability groups (audio, visual, cognitive, physical), you will be able to pool a group of users that would be able to provide crucial comments on the state of your product and help increase the accessibility of the product.

For example, The UK Government has an excellent blog focussed on their digital providings and how they achieve accessible content, you can check here for the gov.uk accessibility blog. They have an excellent overview of how they apply the accessible mindset form design to development and how user testing of components helps them find edge cases that couldn't be foreseen. For example, here is a post on designing an accessible autocomplete for the gov.uk platform.

Conclusion

As we can see, there is a load of considerations to be made to facilitate accessible and inclusive design. If however we strive to solve common issues, stick to the accessible design principles and strive to include more people in our processes, we can make our products and services far more accessible than before and push things forward for the better.

Resources

• Inclusive design principles - provide comparable experiences
• What's 'large text' in WCAG 2.0 parlance?
• Creating accessible data tables
• Quick Reference Web Accessibility Principles
• WCAG Success Criterion
• Designing button states
• What is user testing
• Usability testing rules
• The gov.uk accessibility blog