Weeknote: Creating a roadmap for Accessibility on GOV.UK

tobiogunsina Product management, weeknotes 1 Comment

I didn’t write a weeknote last week because I was not feeling well over the weekend, so this weeknote will cover the 8 days I’ve worked in the last 2 weeks. 

Last week started on a high note for me. It’s also mid year performance time so

I started the week by reading the feedback I got from the people I’ve worked with in the last  6 months. It’s such a good feeling to know how much difference your work (and how you do it) makes.

There was a lot of great feedback about setting clear direction even in uncertainty, helping the team progress, great balance between attention to detail and seeing the big picture, good listening and working with the team on decisions, strategic thinking, making sense of complexity, using appropriate tools and techniques etc. Also people appreciate me being open, calm and positive even under pressure. Heyo! 

I could go on but let me tell you the highlights of the last 2 weeks

What went well

We spent some time thinking about front end technical debt, how it affects keeping GOV.UK accessible and what’s needed to pay them down. They affect accessibility because they make it harder to keep GOV.UK up to date with the latest changes to the design system and to GOV.UK components. 

Using the output of that session and roadmap input sessions we had with the team, I worked with the delivery manager and tech lead to create a roadmap for GOV.UK accessibility. The team has reviewed and discussed the first draft and we’ve updated it. 

The roadmap covers the areas we hope to focus on over the next 6 to 12 months. We’ve also created an accompanying note that provides some detail about what’s on the roadmap, key decisions we made while creating the roadmap and recommendations that are out of our scope but have significant impact on the accessibility of GOV.UK

Our Goal is to make sure GOV.UK is usable to as many people as possible and to keep GOV.UK accessible in a sustainable way so that in the long term, we don’t need to fix lots of accessibility issues in a short time as we’ve done recently.

To do this, we’ll focus on these themes: 

  • Finding and fixing other known accessibility issues
  • Updating GOV.UK to fully use the latest version of the Design System and GOV.UK publishing components
  • Implementing strategies to help GOV.UK remain accessible
  • Monitoring accessibility of GOV.UK content

We’ve shared it with the management team and we’ll spend some time with them to discuss the roadmap next week. The roadmap is a simple excel sheet because let’s be honest, it does the job well enough. 

I also spent some time planning the next sprint which will focus on auditing the front end apps to identify what we need to do to upgrade them and identify templates that are out of date. We are also still working on some of the Web Content Accessibility Guidelines (WCAG) 2.1 failures that we couldn’t fix before the deadline. 

I prepared for and talked about our work on accessibility at the GOV.UK show and tell. I think I’ve gotten better at storytelling so it went well. 

What could have been better

I was not feeling well for a few days so that sucked. 

I spent some time answering accessibility related queries that are forwarded to me. One of the queries was questioning a change we made to the title pattern of topic pages. We considered it a small change to resolve some of the accessibility issues with duplicate titles but it seemed to have been received badly by a department. 

It’s not yet clear if there actually was any impact but it surprised and upset them. In hindsight, we should have told them about it to manage the situation (and relationship) better and address any concerns.

In other news

I’ve officially started doing compressed hours. I now do 10 working days in 9 days and have every other Friday off so yay! 

I spent some time doing some compulsory training on being responsible for information. 

I attended a session where we discussed technical and product debt. Technical debt is a term to describe the additional costs incurred in software development due to a shortcut or compromise taken. It’s not always technical though, they can also result from product decisions and have long lasting negative impacts. Those conversations were useful and certainly will be something to bear in mind when making product decisions 

I filmed the trailer for the Introduction to product management course that will be going public soon. 

I also found out I’ll be line managing another product manager so looking forward to that!