The User Accessibility Steps

24/02/23 | A. Understanding User Needs | All Guidelines and Documentation

Version 1.0
for the Visually impaired

Version control table

Version	Date	Comments
1.0	24/02/2023	Published Document

1. Introduction

Accessibility in design allows users of diverse abilities to navigate, understand, and use a digital service. Improving a product’s accessibility can enhance its usability for all users, including those with low vision, blindness, hearing impairments, cognitive impairments, motor impairments or situational disabilities

This means that the Digital Service Factory Team (DSF) make digital services better for everyone by considering some basic usability principles. A checklist should be used from the “Web Content Accessibility Guidelines (WCAG)” as a reference point. Based on this, the digital Service meets WCAG, Conformance Level A and AA.

This User Accessibility steps document is focused on testing people with visual impairments. During the Accessibility Testing, Web accessibility evaluation tools and software programs should be used, to help to determine if the eService content meets accessibility guidelines.

2. Setting up the Test

Members of the team should contact people with visual impairments (i.e. the school with visual disabilities) and ask for participants for testing purposes. As soon as the team has the names and contact details of the participants, meeting arrangements should be processed. The suggested location should be the area of the participant.

All participants handle websites and apps differently. To be able to use websites or apps, visually impaired users often use tools with personal settings (assistive technologies). So, in order to test a digital service, realistically, it might be better if they use their own device(s).

Arrange invitations with each participant and note-taker (that will be assigned) and decide the exact date, time, and location of the accessibility testing session.

3. Assign note-takers for the accessibility testing session

The member of the team who will handle the accessibility testing (probably the User researcher), should assign roles to other members of the team to note-take while the accessibility testing session is running. Note-taking can be done by both, the member who is running the accessibility testing and the note-takers. Be sure to brief the note-takers, ahead of the sessions, so that they know what to expect and to know what notes are most important to capture. Any personal details captured during the session must be GDPR compliant to protect the participants’ data and confidentiality.

The Notes to capture should be based on the Areas that the service should be tested on.

4. Plan the Areas that the service should be tested on and prepare the checklist

Areas that the service should be tested on are the following:

Generic Testing
Navigation
Dark Mode
Content
Global Code
Keyboard
Images
Headings
List
Links and Controls
Tables
Forms
Error Messages
Colour contrast
Mobile and touch

Based on the areas above a checklist is prepared and should be followed while doing testing with the participants.

If the service that needs to be tested, requires users’ credentials to log in, then make sure that they have been prepared before the meeting date.

Prepare all the test scenarios that will be used to be able to verify that all areas mentioned in paragraph 4 are tested.

An example of the above (test areas, scenarios, sample credential table) is shown in the Accessibility Testing Report.

5. Do the research and take notes

Send kind reminder email invitations to each participant and note takers who will join the accessibility testing session for the accessibility testing meeting.

Attend the testing location 15 minutes before introducing the team to the participant users. Make everybody feel comfortable and get ready to start the accessibility testing session.

Explain the scenarios that will be used to test the areas in paragraph 4, that need to be tested and start the accessibility testing.

As soon as the accessibility testing session is done, meet with the note-takers to combine and clean all the notes taken during the session. This means removing duplicates and making sure the notes are legible and ready for analysis.

6. Analyze Findings from the accessibility testing

To synthesise the findings, analyse all notes, issues, errors, suggested points, difficulties, and strong points. Study all points written down from the Checklist in the Accessibility Testing Report as well as the extra notes taken from the note-takers. Prepare a list for the designers, analysts, and developers. Decide which are the points (issues/errors) that affect the service to move to the next phase and need to be corrected, which are the “good to know” ones and which are the ones that do not affect this phase but the next.

If some issues/errors need to be corrected in the current phase then, decide if there are points that need to be re-tested for necessary planning. If yes, then arrange re-testing.

Once the analysis of findings is done (paragraph 6 above), prepare a meeting with the team and share all the above findings widely with the team. Inform the Product Manager (PM) about the issues/errors that need to be corrected at the current phase, possible timeline issues and possible project planning changes for their further actions.

The presentation should include:

The scope of testing
The Scenarios that were used
Process followed
Participant’s type of disability (ie. 30% blind, 70% blind, totally blind, etc)
The areas that were tested
Results of each area and recommended actions
Participant points & possible participant comments/suggestions
The Issues/errors/suggested points
What needs to be corrected at the current phase, what is the next phase and what is good to know
Possible timeline issues
tools used while testing visually impaired participants
Discuss possible further rounds of accessibility testing (according to findings) to verify that the corrections/changes to the design or service successfully meet the user’s needs in accessibility testing.