DEV Community: Colin Oakley

Evaluating accessibility

Colin Oakley — Thu, 27 May 2021 08:12:52 +0000

One thing that is often asked when I am talking about accessibility is how you evaluate it on a website or service.

There isn't an easy answer to this question as it is a complex mix of technical implementation, design, and tooling.

Getting Started

The most recent evaluation I did was with an interaction designer, the first thing I did was use a Miro board to document the high-level flow of the service.

This helps me understand:

what the service is doing
what sort of patterns are included
any sticky points

This gives us a visual representation to document issues against.

Automated checks

The first thing I always do is get a feel for the page

Does it have landmarks?
Does it have form elements?
Does it have any interactive elements?
Does the header document outline follow a standard order?
Does it respond when you change browser width?

Usually, this will help narrow down what sort of issues might happen on a page.

From here I'll run some browser plugins to see if anything obvious is flagged

These are by no means the only automated checks, and we need to appreciate that these sort of plugins, will only flag a limited selection of issues.

"Our research backs this up. While the tools picked up the majority of the accessibility barriers we created – 71% – there was a large minority that would only have been picked up by manual checking." from What we found when we tested tools on the world’s least-accessible webpage.

Manual checks

Often there is a lot of subtlety to accessibility issues semantically an image may have an alternative text tag, but that doesn't mean it actively describes the image.

The manual check falls into two parts largely, understanding and interaction.

For interaction I'll generally go through this list:

Check tab order
Check focus style on interaction elements
Check page can be used by only a keyboard (this related to two)
Check interaction with the page
Check error states
Check common input issues (i.e trimming spaces)
Check using a screen reader
Check buttons and links are used in the right context and Voice Control

Checking the page conveys understanding ends up being more of a content check

Check page titles follow best practice
Check form fields are descriptive
Check errors are descriptive
Check link text is descriptive, this may need a screen reader as sometimes context is hidden.
Check any aria/hidden content is read out as intended

Service level checks

There is a couple of functions we need to check at a service level

Service has a skip link
Landmarks and navigation is consistent
Session timeout
Check your answers

Alignment

The final part of the evaluation is to check if the service is consistent with other GOV.UK services and documented patterns.

Dealing with issues

The first step is to validate is if the issue is a false positive.

From here we need to decide if it is an issue of implementation or something we are consuming.

If for example we are using an external package, we will need to work out if the issue is already documented, or if it is something new. With the GOV.UK frontend we would raise this on GitHub.

It won't always be a technical fix either, a lot of complicated accessibility issues will need to be designed out of a service.

A recent example of this is the conversation around the use of an accordion where we should a step back, and change how we present the information.

Outputs

The first time I did this I gave people an Excel list, this lacked the context needed to where it was happening in the service.

I've now started to use that Miro as a visual representation of issues grouped into different types and attached related -Web Content Accessibility Guidelines (known as WCAG 2.1) which I walk through with the team to set context and talk about the barriers it will create.

Miro is really nice for giving context but bad as a document store. The next step is to raise issues as output to a project board (like Jira or GitHub Projects), this will allow better tracking of issues, tagging, and give a consolidated view.

On a team who is responsible for accessibility?

Colin Oakley — Tue, 18 Jun 2019 10:31:16 +0000

There is always a slightly weird moment on most teams I've worked on where a conversation happens about who is responsible for accessibility.

The truth is no one person is responsible for accessibility, we as a team are responsible. It should be a principle of the services we deliver that they are by default accessible. This will become part of UK law later in the year for Government services.

For me as a front-end developer, I can build something that is semantically accessible, this doesn't make it useable.

Everyone on the team needs to advocate for accessibility, we need to understand what our roles are responsible for, and how they fit together to create accessible services.

It is worth having this conversation as a team, so you can get a better understanding of it.

User Researchers

We should be doing research with a wide range of people who use our service. I'm never overly keen on persona but it is a great way to raise awareness on a team of the different types of challenges a user will face.

Another important thing is making sure we regularly test with people who will use our service, who use assistive technology. This sometimes can be quite difficult to find, so we can do usability testing with people who use the tools.

This will give us some context that our service is usable, but might not help us understand if the person's user need is met by the service.

Understanding disabilities and impairments: user profiles

Content and Interaction Designers

There are lots of things a designer (both content and interaction) needs to take into account when designing a service, such as making sure we have thought about focus state, colour contrasts and clear language.
As designers we need to understand WCAG 2.1 and the core parts of it, so we can influence how we design.

Developers and Testers

For me, as a developer, it is a given that I use the right mark-up for a website, regardless of the technology used.

We also need to build testing tools into our process, I know they won't catch all the things (see link below), but building them into pipelines is a way to catch big problems early.

We can also sanity check things like is it keyboard accessible? and we can build these into our definition of done.

We can also sanity check our services with tools, we need to appreciate that we will not use the tools in the same way as an actual user.

Product Owners

Like everyone product owners need to understand the types of users that might be affected by issues. They also need to make sure the team has the time and space to do the testing and deal with the outcome.

They need to be an advocate of the work that is going on and make sure stakeholders understand what work is going on, and why it is important.
Building a digital product doesn't make the other support channels accessible, but we can use this to highlight issues.

What if this isn't happening?

Most of the time, I've found starting to have the conversation about what accessibility needs we have for our users is enough to kick start better conversations around it, if it still doesn't happen, here are some things you can try to get it going.

A lot of these activities will hopefully help to get people to understand more about accessibility and start to build empathy with people who have disabilities that we need to think about when designing and building services.

Make it visible - I linked to the excellent home office accessibility posters earlier, the more you can do in your team space to make the problem visible the better. Start putting accessibility design challenges on the wall, calling out accessibility issues (be it bugs or usability) as bugs, tech debt, or features all the starts to put it at the front of people's mind.
Tell the story - taking the team out on user research with people with access needs is a good way to raise awareness, get buy-in and highlight issues.
Run a workshop - workshops are another great way to build empathy, either using assistive technology (like a screen reader) to navigate your service or you could get a set of vine sim specs to help simulate issues
Make it part of the process - as developers, we already have parts of our process like unit testing, there is no reason we can't include accessible acceptance criteria.
Get audits - reaching out to other teams in your company or even outside to review your service is another way to get great feedback
Make it open - sharing the issues you are having and how you've fixed them is another great way to make it more visible as a team and company and to help other people learn - Bulb did a great open accessibility audit.

working with templates

Colin Oakley — Tue, 21 May 2019 08:08:58 +0000

I've worked with a number of templating engine across different systems which vary quite a lot.

A lot of the approach you take to building something will depend on the features the engine has.

Rather than give an overview of the language, I thought I'd talk a little about how to apply some of it.

I'm going to talk a little about nunjucks - it is feature rich, well supported and has extensive docs.

For this, I've mashed together some bootstrap templates to make a pretty generic looking website.

You can see the code on github.

With nunjucks there are three features we need to talk about before we start deciding how to start to split up the page.

Extend - this allows us to define a base template, and then override parts of it within the child template. This is known as template inheritance.

Includes - this allows us to pull another template into our current template

Macro - these are functions, you can define a reusable chunk of code.

Base template

You would normally hope for more than one page, then you can make a better judgement about what you should turn the elements of the page into, but given the page above, the first part we will work out is a base template

We will be having one base template that all other pages will extend out of this, in the case above we'd have one with the header and the footer in it.

This template will have a series of blocks that we can override in a child page - so we will have a home page that extends the base template.

A block is a named space that can be replaced by the child template.

If we assume that the header and footer won't need to be replaced then our base template will look something like this:

<!doctype html>
<html lang="en">
<head>
// stuff for header
</head>
<body>
// navigation html

// block: content

//footer html
</body>
</html>

Even within this, we have some options, we could already extract the navigation and footer to their own either macros or includes.

When I look at templating I am looking at how we compose different elements, once we start splitting it down into smaller chunks we start to think about how they are used.

The aim is to make it more maintainable, though if we over extract then we can be in danger of making it too complex.

Check out the full base template, you can see I've moved navigation and footer into includes, this is to isolate them.

The home page

We can now create a page by making a file like the one below


{% extends 'templates/base-includes.nunjucks' %}

{% block pageTitle %}

{% endblock %}


{% block content %}
// home page content lives here
{% endblock %}

We can now start working out what to do with our home page content, this can be broken down into three parts.

jumbotron
subscription information
three column content

We will assume that all three of these are includes for the moment, these can now be included in new pages, so if we want to make an alternative version change what we include, or if we want to update a section, we are now changing a smaller file.

What can we make a macro

The thing that stands out that will work as a macro is the subscription information.

We have three repeating blocks, if we look at all three we work out what is common so we have:

// classes

// header

// price

// features

// button

We can start by building a macro that takes one parameter - the title, then build up the rest.

The macro is called priceBox and takes a parameter title, this is then printed in place of the original header.

{% macro priceBox(title) %}
<div class="card mb-3 shadow-sm">
      <div class="card-header">
        <h4 class="my-0 font-weight-normal">{{ title }}</h4>
      </div>
      <div class="card-body">
      </div>
</div>
{% endmacro %}

To use this we first import it to our other template, and then call it, below is the wrap around include we are using.

{% from '../../components/price-box.nunjucks' import priceBox %}

<div class="container">
    <div class="card-deck mb-3 text-center">

    {{ priceBox('Free') }}

    {{ priceBox('Pro') }}

    {{ priceBox('Enterprise') }}

    </div>
</div>

There are two ways to import a macro, you can read more about import over at the docs.

We can now expand our macro to take price, features and buttons.

Below is an example of an extended version, I've named the variables we are passing in so it makes it a little clearer.

We can give these defaults in the macro if needed, for this it doesn't really need it.

Features takes an array of items that we loop over in the macro and button takes an object so we can supply multiple values.

    {{ 
        priceBox(
            title = 'Free',
            price = '0.00',
            features = [
                '10 users included',
                '2 GB of storage', 
                'Email support', 
                'Help center access'
                ],
            button = {
                text: 'Sign up for free',
                classes: 'btn-outline-primary'
                }
            )
    }}

Our macro now looks like the below, if no futures are provided then we default the text.

{% macro priceBox(title, price, features, button) %}
<div class="card mb-3 shadow-sm">
      <div class="card-header">
        <h4 class="my-0 font-weight-normal">{{ title }}</h4>
      </div>
      <div class="card-body">
        <h1 class="card-title pricing-card-title">${{ price }} <small class="text-muted">/ mo</small></h1>
        <ul class="list-unstyled mt-3 mb-4">
        {% for feature in features %}
          <li>{{ feature }}</li>
        {% else %}
          <li>No features</li>
        {% endfor %}
        </ul>
        <button type="button" class="btn btn-lg btn-block {{ button.classes }}">{{ button.text }}</button>
      </div>
</div>
{% endmacro %}

We now have the same page as we started with, but broken down into re-usable chunk, we can now build additional pages.

Nunjucks also has a number of built-in filters you can also extend it to add your own.

templating - from html to macros

Colin Oakley — Tue, 02 Jan 2018 21:15:24 +0000

Whenever I am pairing with other developers we always seem to hit a similar topic; abstraction.

There is ever a clear-cut answer to that question, as it requires the context of the code and the state of the application.

Overly abstracted code can make changing it difficult and hard to comprehend whereas no abstraction can lead to bloat and repetition.

Below is an example of a text input form GOV.UK Elements.

The examples below use nunjucks.

<div class="form-group">
    <label class="form-label" for="ni-number">
        National Insurance number
        <span class="form-hint">
            It's on your National Insurance card, benefit letter, payslip or P60.
      </span>
    </label>
    <input class="form-control" id="ni-number" type="text" name="ni-number">
</div>

Form elements always seem a very clear example of where we should do an abstraction - they have set structure and usually are used multiple times on a site.

When we look at making a reusable form element, we do it with the composition of the makeup of our HTML in mind.

There are a couple ways we could break this out, the first would be so that each of the parts of the code would have its own macro - this would mean each part would be usable within other form elements.

This would look like this:

form-group wrapper
label
input

Using nunjucks we'd end up with something like this:

{% macro input(id, name, value='') %}
<input class="form-control" 
        id="{{ id }}" 
        name="{{ name }}"
        type="text"
        value="{{value}}">
{% endmacro %}

{% macro label(for, label, hint) %}
<label class="form-label" for="{{ for }}">
    {{ label }}
    <span class="form-hint">
        {{ hint }}
    </span>
</label>
{% endmacro %}

This would allow us to compose our UI like this,

{% from "forms.html" import field, label %}

<div class="form-group">
    {{ label('ni-number', 
            'National Insurance number',
            'It\'s on your National Insurance card, bene...') }}

    {{ field('ni-number',
             'ni-number',
                niNumberValue) }}
</div>

This allows label and field to be composed to produce other form elements, they could also be wrapped in another function to produce a form element, I'll come to this later. We could also look at moving the form-group div to a macro.

This could also be done as a single macro.

{% macro textInput(id, name, label, hint, value) %}
<div class="form-group">
    <label class="form-label" for="{{ id }}">
        {{ label }}
        <span class="form-hint">
            {{ hint }}
        </span>
    </label>
    <input class="form-control" 
        id="{{ id }}" 
        name="{{ name }}"
        type="text"
        value="{{value}}">
</div>
{% endmacro %}

This encapsulates both the previous macros in one call, this makes it less composable but also has the full element.

The second method will quickly become bloated if we need to add on additional options for example styling, input type or additional HTML properties.

We could also make a hybrid of the two methods, though as we start to do multiple layers we start to make our code less readable and we need to be more mindful when we make changes.

{% macro textInput(id, name, label, hint, value) %}
<div class="form-group">
    {{ label(id, 
            label,
            hint) }}

    <input class="form-control" 
        id="{{ id }}" 
        name="{{ name }}"
        type="text"
        value="{{value}}">
</div>
{% endmacro %}

This in hindsight feels like the right balance, textInput is encapsulated but the label can be re-used across different macros.

My final macro has the following inputs

Name	Description
name	sets the name of the input
id	sets the id of the input, and the for of the label
label	sets the text of the label
hint	sets hint text within the label
value	sets the value of the input
error	sets the error message
maxlength	sets the max length of the input
classes	object used for styling elements

This has various states, including optional fields and error states. This after a couple of iterations seemed like the right level of abstraction in the application context, though I think there is more to do with moving the label to its own macro and being called within the element.

{% macro textInput(name, id, label, hint, value, error, maxlength, classes) %}
    {% if not id %}
        {% set id="input-" + name %}
    {% endif %}

    <div id="{{id}}-form" class="form-group{% if error %} form-group-error{% endif %}">
        <label for="{{ id }}">
            <span class="{% if classes.label %}{{ classes.label }}{% else %}form-label-bold{% endif %}">{{ label }}</span>
            {% if hint %}<span class="form-hint">{{hint}}</span>{% endif %}
            {% if error %}<span class="error-message">{{error}}</span> {% endif %}
        </label>
        <input
            class="form-control{% if classes.input %} {{ classes.input }}{% endif %}"
            id="{{ id }}"
            {% if maxlength %} maxlength="{{maxlength}}"{% endif %}
            name="{{name}}"
            type="text"
            value="{{value}}">
</div>

Whenever you make a deliberate decision to try and make re-useable code there is always going to be a trade-off in functionality, readability, and maintenance.

Keeping things self-contained gives the ability to refactor it later with minimal change.

Feel free to add how you'd do this, or message me on twitter