engaging and accessible elearning presentation handout ? web viewput a period at the end of every...
Post on 21-Feb-2019
Embed Size (px)
Engaging and Accessible eLearning Presentation Handout
eLearning for All: Creating Engaging and Accessible Online Training
Table of ContentsEngaging and Accessible eLearning3Main Considerations for CBTs3Who else benefits?3Use Headings4Choose a readable font4Interactions like quiz questions5Interactions that typically dont work6Quiz Instructions for Screen Reader Users Using SoftChalk6Helping a JAWS user (and the developer and everyone else) find the next question easily6Asking good questions8Which Interaction types should you use?9Alternative Text for Images11Best practices11Color Contrast and Your Templates12Pick a template with good color contrast12Colour Contrast Analyser12Test your Style Template13Gradients and Patterns15Images in the Banner16Hyperlinks17Open most links in a new window17Descriptive link or exposed URL?18Top tips for hyperlinks:18Short URLs?20Links for emails and downloadable documents (pdfs, word)21Video21Basic Guidelines21Video Accessibility for Blind22Accessible Video Players23Video Accessibility for Deaf Providing Captions23Additional Accessibility Tips and Guidelines24Does your CBT allow users to modify contrast settings?24Left Justify most Text and Objects25Coding Tips26Eliminating related videos at the end of embedded YouTube video26Email hyperlink tip27JAWS Tips for Training27Tools to Help you Evaluate and Create Accessible content27Web Accessibility Checkers27Contrast Analyzers28
Engaging and Accessible eLearningMain Considerations for CBTs
We are trying to develop training that works for EVERYONE. There are several groups that need special consideration, some of which are users of Accessible Technology (AT):
Blind users (employ screen reader software)
Low Vision users (employ screen magnifier software and/or screen readers and/or modified color settings)
Keyboard-only users (may only strike one key at a time)
Deaf Users (need captions/transcripts for audio)
Anyone who uses special technology to help them access the information on their computers are using Assistive Technology, or AT for short. Following Accessible Design Principles helps all these users AND improves the training for other users too.
Who else benefits?
Power users (keyboard shortcuts)
Users in loud environments
Users with motor impairments
The user who just sprained their wrist
Using headings (Heading 1, Heading 2, Heading 3) on each page helps you organize what you are sharing. Real headings are created when you choose a heading style from the text style drop box. Headings also help a blind user navigate your page. Just making up your own headings (pseudoheadings) by bolding and changing the font size or other text attributes doesnt cut it.
Headings also help Softchalk create a table of contents and the on this page sidebar.
Choose a readable font
Font choice helps readers read more easily. Most experts think that for web applications, a sans serif font is best, but not all are created equal. In the screenshot below, you can see that the number one, the lower-case L, and the capital I are often similar looking which can cause problems, especially in situations like passwords. The same is true for zero compared to the capital o.
Of the fonts shown below, the authors like Tahoma the best for distinguishing visually among these letters and numbers. Font known to be the worst to use is Franklin Gothic Book.
Interactions like quiz questions
Any interactions, activities, quiz questions need to be keyboard navigable, first and foremost. Can you tab to different options, select using the spacebar or enter key, check your answer all without touching the mouse? They also need to be operable with a screen reader (sometimes you can navigate with a keyboard, but the buttons arent correctly labeled so a screen reader cant see them).
Interactions that typically dont work
Since the following usually require clicking and dragging or moving the mouse, they are usually not considered accessible. It may depend on the authoring tool.
Drag and drop
Quiz Instructions for Screen Reader Users Using SoftChalk
Screen reader users get used to how to select items that are a set of radio buttons or checkboxes, but in the case of SoftChalk, it doesnt group the radio buttons, so some instructions can help your screen reader or keyboard-only people:
KEYBOARD-ONLY USERS: Arrow down through the questions. The radio button for each answer comes before the text. To choose your answer, use the space bar or enter key when you hear the text you want to select. After you have made your selection, arrow down and select the Check Answer button before you move to the next question.Feedback is found directly below the Check Answer button after it is selected.
Helping a JAWS user (and the developer and everyone else) find the next question easily
JAWS users get good at skimming web pages in various ways. One way is to jump from heading to heading (pressing the H key does this). If your CBT is in HTML (web page format), putting a title before each question that is also a heading (usually Heading 3) makes it easier to find and navigate the quiz questions, especially if the user has to go back and try again.
This also helps the SoftChalk developer because, as the screenshot below shows, in SoftChalk Create, you cant tell which question you are looking at without some title outside the quiz popper itself.
Screenshot of editor's view of several quizpoppers showing the Heading 3 titles labeling them, and the Heading 3 at the end which says End of Summary Assessment.
Put a title before each question, labeling it as question 1, question 2, etc.
Make these titles heading 3 (or 2) so JAWS users can easily navigate to the next question.
Put an end of quiz as a heading 3 (or 2) at the end of the set of questions to easily tell when the quiz is over.
Asking good questions
Compare these two multiple choice questions:
1. The acronym TGIF stands for "Thank Goodness
What are the last two words in the acronym TGIF?
Listening to a screen reader read the first question convinces us the first one is not ideal for screen readers. JAWS reads the homemade blanks as four or more blanks with no indication of the spaces, so its not at all clear you are looking for two words.
So avoid fill in the blanks in the way you write your question prompt, if using multiple choice questions. Rewrite them to be actual questions (rather than statements with blanks) whenever possible (like the second example above). If you must use fill in the blank, use a sentence completion type quiz (with dropdown choices) or a multiple blanks question type, not a multiple choice one.
Which Interaction types should you use?
Not all quiz questions (and other interactions) in eLearning development tools are equally accessible. SoftChalk for one has attempted to support otherwise inaccessible quiz poppers with a neat keyhole icon that is supposed to provide an accessible version of the activity for AT users.
However, if you see a keyhole icon, BEWARE. It means that the interaction as a non-AT user sees it CANNOT be seen or read by a screen reader. Make a sober assessment about whether what the keyhole provides really provides an equivalent, accessible alternative. In our opinion they do not. Heres an example, using a crossword puzzle quiz popper in SoftChalk:
When you select the keyhole icon, a new window opens (shown below) with a list of clues, including how many letters it is. It does not include across or down, nor which letters intersect which other letters.
At first glance, this seems like a suitable alternative. It even shows something the non-AT user doesnt easily find out: the number of characters in each word answer. But is this accessible? Consider these questions:
Is it equivalent? Thats the goal when providing an alternative.
Does it provide an interaction?
Is there a way for the user to know if they got the right answer? The original interaction turns yellow, and at the end they get scored.
Do they get a score?
Does it count toward their total score (if its a graded assessment)?
Because the alternative activity cannot be checked for correct answers, nor scored, it doesnt really qualify as an equivalent alternative.
Alternative Text for Images
A blind person (or a low vision person) needs to know what your images are all about. Thats what alternative text, or alt text, is for.
1. Put a period at the end of every alt text, even if it is just one word. This causes the screen reader to pause briefly, making it easier to tell that the alt text has ended.
1. If using acronyms or initialisms, consider putting a space between each letter so JAWS will say it letter by letter. Alternatively, if it is a pronounceable acronym like NASA, ensure JAWS is reading it correctly by listening with JAWS and adjusting the spelling as needed (NOTE: experienced JAWS users can set up their custom acronym definitions so this step wouldnt be necessary for them).
Rarely if ever use the Long Description. It creates a hyperlink to a new web page that opens and contains only the text in the long description. Heres a real (and terrible) example we found (dont do this!):
Perhaps the long description MIGHT be a good idea for a really complex infographic image, so a blind user could read all the data in the graphic. Another example might be a screenshot of a spreadsheet or graph. However, SoftChalk as a developme