⚠️ Disclaimer
📝Note
This exercise is hosted on the GitHub repository of our partner NGO, Code Your Future (UK), and not on a MigraCode-owned repository. We are part of a European network where we share resources and support each other as we share the same mission - to provide free, high-quality tech education to our communities.
The exercise works as intended — you are free to fork and clone the repository as usual, if required by the exercise. However, please do not make any pull requests to the original Code Your Future repository.
Lastly, if there are any mentions to CYF Slack channels please write a message into our MigraCode class channel instead.
🔗 Accessibility: Record a Goose
Learning Objectives
Record a goose sighting
What to do
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 you from finding answers before you’re ready to go through them as a group!
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?
- Install and run Accessibility Insights. What advice does it give you?
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.
In this course, 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:
🕹️Backlog (30 minutes)
- Find the sprint backlog
- Copy your tickets to your own backlog
- Organise your tickets on your board