πŸ§‘πŸΎβ€πŸ’» prep

Record a Goose πŸ”—

Record a goose sighting

Go to the ‘Record a goose sighting’ exercise

This is a fictional service, to help you record any sightings of geese (geese are awesome). It’s using the GOV.UK Design system, which are WCAG 2.1 AA compliant, and benefits from hundreds of hours of work and testing. However, even if you’re using a Design System, stuff can still go wrong…

There are places where the Design System is misused, misimplemented or misunderstood. This has caused accessibility issues, which range across code, design and content - because accessibility issues can be introduced by all of these disciplines. As such, anyone is welcome to have a go and use this as an exercise!

How to use this

The task is to find as many of the accessibility issues in this site as you can in ~20 minutes.

There is a worksheet, and there is also a list of answers - but give it the full 20 minutes before you look at the answers first, if you’re working through this alone!

If you are running this as a group workshop, there is an answerless ‘Record a goose sighting’ exercise, that you can use with attendees. This prevents them from finding answers before you’re ready to go through them!

What testing tools to use

I would recommend working through the site in the following order:

  • Can you access everything by pressing the tab key?
  • Does WAVE show any errors, or highlight any issues with the HTML structure?
  • Does the colour contrast tab on WAVE throw up any errors?

Government Digital Services have recently published how to conduct a basic accessibility audit, which is worth a look at too.

Testing like this is a good way to identify basic accessibility issues. It would not replace an audit against WCAG 2.1 to level AA, and its ~50 criteria. Why still do it? These are tests that are quick to run, and it’s easier to fix accessibility issues at the start, rather than the end.

Backlog

Learning Objectives

In software development, we break down complex projects into smaller, manageable parts, which we work on for a week or two. These periods are called “sprints.”

A sprint backlog is like a to-do list. It lists what the team has decided to work on this sprint. It’s chosen from a larger list, usually called the “product backlog,” which holds the entire project to-do list.

The backlog is a set of work designed to build understanding beyond the concepts introduced in the course prep. For your course, we have prepared a backlog of mandatory work for each sprint. You will copy these tasks into your own backlog. You can also add any other tickets you want to work on to your backlog, and schedule all of the tasks according to your own goals and capacity. Use your planning board to do this.

You will find the backlog in the Backlog view on every sprint.

Copy the tickets you are working on to your own backlog. Organise your tickets on your board and move them to the right column as you work through them. Here’s a flowchart showing the stages a ticket goes through:

flowchart LR Backlog --> Ready Ready --> in_progress in_progress[In Progress] --> in_review in_review[In Review] --> Done

activity

  1. Find the sprint backlog
  2. Copy your tickets to your own backlog
  3. Organise your tickets on your board