What you should be testing to improve your elearning accessibility

May 26, 2021

Last week was Global Accessibility Awareness Day. In the build-up to this, we published a series of articles to help you improve the accessibility of your elearning. This article rounds off this series with some guidance on how to perform Quality Assurance.

 

What is QA?

Testing elearning is known as Quality Assurance (QA) and is a vast area that includes many facets. It is one of my greatest passions, and I could, frankly, talk all day if you let me! Good QA can make the difference between an elearning module connecting with the learner or missing the mark. This is so much more than proofreading for typos and grammatical errors.

QA reviews should include reviewing:

• Content/text – Is it easy to read, it is clear, is it accurate, is it the right tone of voice, are there any errors or inconsistencies?
• Visuals/ graphics/animations – Are they good quality, consistent, are there errors, do they make sense, do they show diversity?
• Audio/voiceover/music – Is the volume right? Is the voice clear? Is it easy to understand and engaging?
• Functionality – Can they navigate logically, go back through the content easily, complete drag and drop interactions without issue? Are resources available?
• Quiz/assessments – Are quizzes set up correctly? What happens when you get questions correct/incorrect? Are the scores passed correctly back to the learner and the LMS?
• Accessibility – You will have to keep reading for this…

 

Why good QA matters…

Good QA means the learner:

• Can be focussed on the content.
• Is more engaged as the module looks, sounds, and feels like the organisation.
• Is confident the module is technically accurate and up to date.

Poor QA means the learner:

• Becomes frustrated by unnecessary distractions/errors and complex navigation/interactions.
• Is unable to complete interactions, the module and/or has incorrect information about their completion on the LMS.
• Loses interest in the content.
• Lacks confidence in the standard of services provided and, as a result, the topic.

It also ensures that the design and development process is smoother and faster, and there is less work for internal reviewers.

 

What is an accessible elearning QA?

An accessibility QA is the process of checking a piece of elearning to ensure it offers the best experience it can for users.

At Little Man Project, we use a process of regression testing for all our QA’s. This means each module is repeatedly tested until it passes. On average, a module will be QA’d around 30 times before it is signed off at every stage in our design and development process. This process involves three steps:

1. Our developers review the module within the authoring tool before publishing to resolve any visible issues.
2. Our QA team review published versions of the SCORM package on our online review site. Each module will then go through this process until it is ready for the client.
3. Our client’s project team reviews the module to check they are happy it represents their view of the topic, is technically accurate and visually represents their brand.

Once the module has reached our Gold stage, the final accessibility amendments are made, and we complete a final accessibility QA.

 

Accessibility QA overview

Before starting an accessibility QA, it is important to understand the different needs that the accessible solutions need to support. Yes, we have a blog post on accessibility profiles for you too!  If you haven’t read it, definitely check it out, as this will be great background on the three areas we are now going to share.

 

Getting started with accessibility QA

When getting started with this type of QA, you will need:

• A screen reader such as NVDA, JAWS, VoiceOver. 
• A colour contrast checker such as WebAIM can be found here.

 

1. Navigating through the module without a mouse (tabbing/keyboard)

Learners who are unable to use a mouse will need to navigate the module using the keys on a keyboard. When reviewing the module the order in which onscreen elements are selected is important. This must follow the logical and instinctive flow of a screen/navigation route. This means each screen should start at the top, and you should be able to tab/key through the content in a logical order (left to right and top to bottom).

The navigation of the screen elements is generally title, body text, instruction text, interaction/navigation buttons before any additional buttons are visited, such as help and resources. If you find that elements on the screen are missed or not visited in the correct order, this should be highlighted in your QA feedback and amendments made.

When reviewing interactions, you need to test if you can complete them all whilst navigating in this way. For example, if you arrive at a drag and drop interaction and cannot complete it, is an alternative accessible solution provided to ensure that you can access this content.

Try to reflect on how the module feels whilst performing this QA and ask yourself:

• Does it feel lengthy and laborious?
• How could it be improved?
• Could the text be reduced in length or interactions simplified?

 

2.  Navigate through the module using a screen reader

A screen reader is a software application that enables people with visual impairments to use a computer and provide information about images, dialogue boxes, navigation elements and files).  Before you QA your module with a screen reader, you might find it useful to use the screen reader on a website, such as BBC News. This will provide you with a bit of experience with the tool and how it feels to use it.

Tip: Some screen readers only read a certain number of words before requiring the user to press a key again. The number of words will be different for each screen reader, but if your chosen reader stops, this doesn’t necessarily mean there is an issue, you may need to press a key to continue.

When testing the module with a screen reader, go through each screen slowly and listen to the description and text being read to you. You might find it useful to close your eyes and navigate through the module to ensure you get a real feel for how people with additional access needs might experience it.

You should consider:

• Can you navigate through the entire course from the beginning to the end?
• Was any content skipped/unread?
• Are the navigation instructions clear?
• Did you hear any text errors?
• Did any of the text sound too wordy or strange when it was read aloud?
• Does audio/ video get played on-demand or automatically?
• Does the ALT text on images make sense, and are they necessary to include or are they adding more text being read without any value to the learner?

 

3. Colour contracts and font checks

You must check that your content can be clearly seen and read. This will include using a colour contrast checker to ensure that the colours used in the module are clear and legible. It’s a good idea to establish an accessible colour palette at the start of your project to ensure the contrasts used are accessible. We often create a list of accessible colour mixes that we can use as a reference.

Note: Your brand colours may not be accessible, so you must check these when adding text to them.

Based on this reference, your developers should check each colour using colour contrast tools. You should then monitor and check this during the QA process.

Accessible fonts should be selected at the start of the design and development process, and a limited number of fonts should be used. You must also ensure the weight and spacing are correct to reduce the effort required to interact with and make sense of the content.

To learn more about using accessible fonts, click here.

 

Summary and close

Once your module has been through your internal QA testing, we would recommend asking people with a range of accessibility needs or who use accessibility tools to carry out a QA of the module for you. This will give you the greatest insight into what works and what doesn’t.

This article has provided a snapshot of the things you should consider when completing accessibility QAs. If you would like more information on general QA good practice and processes, please let us know.

 

Resources

We would also recommend you review the comprehensive elearning accessibility checklist from Skillcast.

 

About the author

Jennifer Compton has been leading the QA process at Little Man Project for 10 years. Jennifer is passionate about delivering progressive elearning modules that connect with the learner and create change.