Testing Keyboard Use and Text Alternatives in Saudi Interactive Training Content

Try this on the next module your team publishes. Put the mouse aside, open the course as an employee would, and press Tab. In a lot of interactive training content, the first few presses work. Then focus disappears behind a video player, a drag-and-drop exercise will not move, or the ‘Check answer’ button responds only to a click. For an employee who works by keyboard, the course ends on that screen.

Images raise a parallel problem. A diagram of a control panel, or an arrow icon used as the only ‘Next’ button in interactive training content, tells a screen reader user nothing without a text alternative that does the same job.

This article shows HR and digital learning teams in Saudi organizations how to test keyboard use and text alternatives in interactive training content: check one real interface, document the barriers with the employees who meet them, and report the findings honestly. It is a practical review, not an accessibility certification.

Why Start with Keyboard Access and Text Alternatives?

Both checks can be run by your own team, and each affects several groups of employees. The W3C’s guidance on Success Criterion 2.1.1 Keyboard in WCAG asks that all functionality be operable through a keyboard interface, and explains why: people with no vision cannot rely on a mouse, people with low vision may struggle to track a pointer, and some people with hand tremors find a mouse very difficult. Speech input, on-screen keyboards, and other assistive technology that emulates a keyboard use the same route, so interactive training content that fails with the keyboard is likely to fail for all of them.

Success Criterion 1.1.1 Non-text Content asks that non-text content has a text alternative that serves the equivalent purpose, and that every control has a name describing its purpose. A text alternative can be read aloud as synthesized speech or read in braille. In interactive training content, this covers photos, diagrams, icon buttons, and image-based questions.

In Saudi Arabia, the National eLearning Center’s eLearning standards, which target government, private, and non-profit institutions that provide, operate, or support eLearning, ask institutions to comply with the approved accessibility standards when designing digital content, and standard 6.4 asks them to engage learners with special needs in assessing whether services and resources suit them. Either way, the message is clear: check interactive training content with real learners rather than assume it works.

Choose One Real Module and Test It Where Employees Use It

Pick one published module that many employees must complete, ideally with several kinds of interactive learning activity, and test it where employees meet it: inside your learning platform, on the browsers and devices they use. An authoring-tool preview can behave differently from the published package, so test the interactive training content that employees actually receive.

First, list every element of the interactive training content that a learner can see or operate. This inventory becomes your test script and the reference for your barrier log:

• Navigation: Next and Back buttons, menus, progress indicators, and exit.

• Questions: multiple choice, drag-and-drop, matching, image hotspots, and sliders.

• Media: embedded video or audio players and their controls.

• Pop-ups: feedback messages, glossary terms, tooltips, and dialog boxes.

• Images and icons: photos, diagrams, screenshots, charts and icon-only buttons.

If the module exists in Arabic and English, test both versions of the interactive training content. Layout, reading direction, and wording differ, and a fix made in one language is often missing in the other.

Run the Keyboard Pass on Your Interactive Training Content

With the mouse out of reach, use common keyboard conventions: Tab and Shift+Tab to move, Enter or Space to activate, arrow keys inside option groups and sliders, and Esc to close a pop-up. For every element in the inventory, note:

• Reach: does it receive keyboard focus? WCAG’s keyboard guidance gives the example of a drag-and-drop activity that also supports cut and paste or form controls, so a sorting exercise needs a keyboard route too.

• Visibility: can you always see where you are? The W3C’s Easy Checks note that people who rely on a keyboard need to know which link or form control has focus.

• Order: does focus follow the screen? In an Arabic layout, that usually means right to left and top to bottom, with feedback reached after the answer.

• Exit: can you leave every component, including video players and dialog boxes, with the keyboard alone?

• Completion: can you submit an answer, read the feedback, finish the module, and see completion recorded?

Note the time too: a screen that takes five minutes by keyboard instead of thirty seconds by mouse is still a barrier in the interactive training content, even if it does not block completion. Captions and descriptions for embedded video are a separate production question, covered in our guide to producing short demonstration videos for Saudi employee training.

Check the Images in Your Interactive Training Content

Next, ask what job each image does in the activity. The W3C’s guidance on image alternative text describes alt text as a short description that conveys the purpose of an image, and the right answer depends on the type:

• Informative images, such as a photo of a gauge, need a description of what the learner must take from them, not a file name.

• Decorative images, such as background textures, should have empty alt text so that screen readers skip them.

• Functional images, such as an arrow used as the Next button, need alt text that describes the function.

• Images of text, such as a screenshot of a system screen, need the text itself in the alternative.

Interactive training content adds one more case: the image that is the question. If employees must spot the hazard in a photo, the alt text cannot give the answer away. Success Criterion 1.1.1 allows a test that would be invalid in text to have an alternative that only identifies the content, so the design team must still decide how an employee who cannot see the image will be assessed on the same skill.

Then listen to the result with the screen reader built into the operating system, in each language version. Alt text drafted by an authoring tool or an AI assistant needs review by someone who knows the task, as our guide to reviewing AI-assisted course creation before approval explains.

Document Barriers with the Employees Who Meet Them

Your own pass through the interactive training content will not find everything. The W3C’s guidance on involving users in evaluating accessibility notes that evaluating with real people identifies usability issues that are not discovered by conformance evaluation alone, and warns against assuming that input from one person with a disability applies to all people with disabilities.

Invite three to five employees who use different methods of access, such as keyboard only, a screen reader, screen magnification, or voice input, to work through the same interactive training content. Participation should be voluntary and arranged through a trusted channel, such as HR’s workplace adjustment process. Give each person a real goal, such as completing the module; observe without helping unless they are stuck, then discuss each difficulty. Log every barrier with:

• Where: the screen and the element.

• What happened: in the employee’s own words where possible.

• Method: keyboard only, screen reader, magnification, or voice input.

• Impact: blocks completion, has a workaround, or slows the employee down.

• Fix and owner: the change, who makes it, and when it will be retested

Record the method, not the reason behind it. The Implementing Regulation of Saudi Arabia’s Personal Data Protection Law requires controllers to collect only the minimum personal data necessary for the purpose of processing. A barrier log needs to know that a participant used a screen reader, not their medical history. Agree the approach with your data protection lead; this is general information, not legal advice.

Report What You Tested, Not a Certificate

The Easy Checks are open about their limits: they cover only a few accessibility issues, a page could seem to pass them yet still have significant barriers, and more extensive assessment is needed to evaluate accessibility comprehensively. Your report on interactive training content should be just as careful. Avoid ‘accessible’, ‘compliant ’, or ‘certified’, and state instead the module, version, and platform tested; the methods used, with participants described by method, not name; the barriers found by impact; the fixes and retest results; and what was not tested, such as color contrast.

Fix blockers first, then fix the cause: correcting a faulty drag-and-drop template protects all future interactive training content at once. If you are choosing a new learning platform, add these checks to your practical demo test before choosing an Arabic LMS.

A Hypothetical Example: Leave Requests at a Riyadh Shared Services Center

The following example is hypothetical and is included only to illustrate the method.

A shared services center in Riyadh launches interactive training content that teaches employees to submit leave requests. It includes a simulated HR system screen, a drag-and-drop exercise for ordering approval steps, a short video, and a quiz, in Arabic and English.

The team’s keyboard pass finds that drag-and-drop needs a mouse and that focus is lost inside the video player; the text-alternative review finds that the simulated screen is a single screenshot and the Next arrow is announced only as ‘button’. Four volunteers, using a screen reader, keyboard only, magnification, and voice input, confirm both blockers and add one more: at high magnification, the feedback appears off screen, so the participant cannot tell the answer was submitted.

The team replaces drag-and-drop with a select list for each step, fixes the player settings, rebuilds the simulated screen as real text fields, names every button, and moves feedback next to the question. Two weeks later, the same volunteers complete the module. The report lists eleven barriers, four blockers fixed and three minor issues still open, and states that the review does not certify the interactive training content as accessible.

Summary

Keyboard access and text alternatives are two of the most practical starting points for checking interactive training content. Test one real module where employees use it, work through every element without a mouse, ask what job each image does, and confirm the results with employees who use different methods of access.

Keep the barrier log specific, keep personal data to the minimum, and report what you tested rather than claiming a certificate. Each module checked this way makes the next piece of interactive training content easier to build right from the start.

Click here. If you are planning or reviewing interactive training content and want to discuss how checks like these fit into your production process, the SkillUp MENA team can talk through your content production requirements with you.