Version 1.0for the Visually impaired
Version control table
Table of contents
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
- Dark Mode
- Global Code
- Links and Controls
- 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 that will join the accessibility testing session for the accessibility testing meeting.
Attend the testing location 15 minutes before and introduce 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 be able 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 there are issues/errors that 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.
7. Share your research findings with the rest of the team
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 in 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.