Making use of the Department for Education accessibility experience lab in Sheffield

"White male, 43 years old" said the AI voice as I had a camera pointed at me. In this case AI hasn't quite got it right yet. But to give you a clue, let's just say I was very happy with a 7-year discrepancy.

Despite AI's rather flattering miscalculation, this was the end of a brilliant and informative session visiting the Experience Lab. We organised this as part of the Vulnerable Children & Families portfolio away day at DfE's Sheffield office.

The session was packed with some great insight! It showed us what Andy Black, Jane Dickinson and Jonathan Mallender do in the Business Engagement & Accessibility Team.

As a multipurpose team, they support colleagues with accessibility needs across the department. They also provide accessibility audits for our websites and digital services. These audits test a wide range of accessibility needs to support everybody.

How we used the experience lab for our away day

At the away day, Jonathan walked groups of colleagues through just a handful of tools at the lab's disposal. Each session made us more aware of the importance of the team's work.

Software based tools that we tried out and discussed included:

• Dragon

  • a speech to text program which requires minimal user interface from a mouse or keyboard

• JAWS

  • a text to speech program, for users whose vision loss prevents them from seeing screen content or navigating with a mouse

• ZoomText

  • a magnification and reading program

  • it enlarges and enhances everything on screen, echoes typing, and reads screen content

• Fusion

  • a hybrid of ZoomText and JAWS

We then tried on different glasses that mimicked visual impairments - these included tunnel vision, macular degeneration and cataracts. The glasses help the team test features that these users might find difficult to see.

As well as visual impairments, the team audits our services against other types of users such as:

• keyboard only - users who have a motor impairment preventing the use of a mouse

• voice activation - users limited to only using voice commands to operate a computer

• deaf or hard of hearing - users limited in their access to audio content

• users with a learning disability that can't understand complicated content

Reflections

The sessions really brought to life the importance of testing accessibility. Imagine testing your website for a blind user. How would you begin? Would you download a screen reader? Would you examine your code to ensure it has alt tags on images? Or would you just turn off your monitor? Probably not that last one, but that is what it would be like to use your service for a blind user.

The importance of accessibility cannot be understated. Accessible content means everyone in society is included and importantly not excluded. The Business Engagement & Accessibility Team's services are invaluable. They make sure everyone can take part.

You can contact the Business Engagement & Accessibility Team via accessibility.support@education.gov.uk or read more about the services provide by the team via Digital Accessibility Hub - Home (sharepoint.com).

Testing our service

The early years qualification team went to the empathy lab to test their service in August 2024.

To make the most of the day in the lab the team took steps to prepare.

1. Read up on the assistive tech before you go.

If you are unfamiliar, so you have some understanding of the commands you might need to use.

We used:

JAWS - https://support.freedomscientific.com/Content/Documents/Manuals/JAWS/Keystrokes.pdfDragon - https://www.nuance.com/products/help/dragon15/dragon-for-pc/enx/dpg-cp/Content/Web/working_with_chrome.htm

2. Plan what you are going to test on the day.

Know which journeys you want to test so can concentrate on the testing and prioritise them in case you don't have time to get through everything

If you can do some manual accessibility testing with tools such as WAVE or axe, this can help you prioritise what you are focusing on in the experience lab.

We tested browsers, devices, colour contrast etc., before going.

3. Prepare how you will record testing notes.

Set something up where you can take notes, so you are not wasting time on the day creating these. Some options could be a spreadsheet, word doc or Lucid board.

Record any issues you have if you can so you can show your team what happened

4. Give yourself enough time.

Focus on your key journeys, try not to pack too much into the day and remember the first few journeys may take you a bit longer to go through as you get familiar with the tech.

5. Divide and conquer.

Having one person going through the journey and one taking notes, telling you the next steps really helps

The room is small right now (they are looking to move to a bigger area). If there are more than 4 of you and you want to use more than one device to test, you might want to book another meeting room (there is one directly opposite - SPP 4.01) and split up.