When you are building an eLearning course, you will want to ensure that all learners—including those with visual impairments—are able to take your course. In many cases, a learner is using a screen reader software like JAWS, so in order to develop an accessible Web eLearning course, the order of the objects placed on a web page needs to be read in a logical order by the screen reader software. When we say a “logical order,” it normally means top down, left to right, just as information would be presented to a person with full visual capabilities. The way that this is accomplished, so that a screen reader can read the web page in this logical order, is for the html objects (text, images, etc.) to be placed in an html document in the actual logical order that you would like them read by the software.
Since we are using Lectora®, to design our eLearning courses and generate the html pages when we publish, we must be aware of how Lectora works, in order for the html pages to place our object in the actual logical order needed for screen reader software.
Figure 1 – Title Explorer tab view of the title
Figure 1 shows a picture of a typical Title Explorer tab view in Lectora, after generating a new course from a template. It has graphics and buttons along with the Course Title and the Page Title, at the title level. Then, there are 3 Chapters, and each Chapter has 3 pages in it. Finally, there is a Test at the end of the course. The way that the inheritance is set up on this course, all of the objects at the title level are inherited by all of the Chapters and Pages. For the test, none of the title level objects are inherited.
So, if we were to publish this course to HTML the way that is set up now, it will publish individual html pages for each page in all of the Chapters, and for each page in the test. For the pages in the Chapters, it will place the objects at the title level FIRST on the html page in the order that they are defined in the Title Explorer. Since the Exit button comes before the Help button in the Title Explorer, it will be placed on the html page first, followed by the Help button. When this is read by a screen reader, it will read the Exit button first, followed by the Help Button. Now, after the title objects are added to the html page, then all other objects are added to the html page following inheritance order in Lectora. So, if there were objects at the Chapter level, this would be added next to the html page, in Title Explorer order. Then, any objects at the Page level would be added next to the html page, again, in Title Explorer order.
If you have objects that you are not inheriting from a higher level, then they are not added to the html on a web page. So, for the test web pages, since the title objects are not inherited by the Test Chapter, they are not added to the html. The objects for the test web page are added to the html starting at the Test Chapter level, in Title Explorer order, followed by any objects on the test pages, again, in Title Explorer order.
Well, that sounds easy enough, right? However, there are a couple of things that you need to be aware of and, of course, there are always exceptions to the rule.
First, when you are developing in Lectora, it is very easy to move objects around visually on the pages. Then, when the html is published and you look at the web pages visually, everything looks fine. But let a screen reader read the web page, and things are not being read in order that you would expect. That is because the way that the objects are placed on the screen to achieve a top down, left to right order visually does not match the same top down, left to right order in the Title Explorer order in Lectora, which we just discussed, for the screen reader to read the objects in the right order. So, when you are moving around objects visually on your web pages in Lectora, ensure that the order that you would like the screen reader to read your web pages is also maintained as well, by checking the order of the objects in the Title Explorer, and reordering the objects in the Title Explorer as necessary.
Second, let’s discuss images and accessibility for a minute. Figure 2 shows a picture of the Logo Placeholder image Properties on the Ribbon view.
Figure 2 – Logo Placeholder image Properties on the Ribbon view, showing the Empty ALT Tag checked ON
For the Logo Placeholder image, we have a property called Empty ALT Tag, which is checked ON. What does this mean? Well, for images, when an image is defined in an html web page, there is an attribute that can be set with the image called the ALT tag. It allows a description to be added with the image of what the image is showing. So, in the world of accessibility and screen reader software, a screen reader cannot tell what an image looks like. However, it can read the ALT tag. If you have nothing in the ALT tag for an image, hence, an EMPTY ALT TAG, then the screen has nothing to read and will just skip over the image, as if the image was not even there (though, visually, we can see that it is). So, when do you set the EMPTY ALT Tag? As a rule of thumb with accessibility, if the image conveys something that is important to the understanding of the web page or your course, then, we would not want to set the Empty ALT Tag. If the image has no importance to the understanding of the web page, then, we usually set the Empty ALT Tag ON. Images that we would leave Empty ALT Tag ON would include background images, border and line images, etc. If you have the Empty ALT Tag checked OFF, then, the ALT tag placed into the html web page is from the Name field on the Properties in the Ribbon view. You should always use a Name that describes the image well. For example, if the image was a boy licking an ice cream cone, then that is what we would use in the Name field to describe the image (“Boy licking an ice cream cone”). It is considered bad form to describe an image using the words “Image” or “Picture,” so you would not describe the image as “Picture of a boy licking an ice cream cone.” The screen reader software will indicate to you anyways that it is reading a graphic image when it finds one with its ALT tag set with a description. Now, if you are listening to a web page with your screen reader and you are not hearing the screen reader find or describe an image (even though you can see the image visually) and it was your intent to have the screen reader read the image, then, the first thing we would check is the Empty ALT Tag and see if it is checked ON. If it is, uncheck it and publish your title again to HTML.
Now, for the exceptions to the ordering rules.
In Figure 2 there is also another Property for the Logo Placeholder image called Always On Top. If this property is checked ON, it will no longer place the object in logical order on the html page but will add it as one of the last items on the html page after all the others. So, why is this property here? Using Always On Top is an easy way to do layering, especially with images, to get one object to be placed on top of another object, so that visually, the layering looks the way you intended it to look. However, with accessibility and screen readers, this can have disastrous results, so, as a rule of thumb, we never use Always On Top checked ON for accessible titles. There is always another way to do the same thing as Always On Top. For example, with images, if you want one image on top of another image, then, just put the image that is supposed to be on top AFTER the other image in the Title Explorer, and you will have achieved the same results. There is one exception where it is ok to use Always On Top with accessible courses (an exception to the exception). Always On Top can be checked ON IF the object is an image AND Empty ALT Tag is also checked ON. If you remember from previous, if the Empty ALT Tag is checked ON, the screen will not read the image anyways, so, it does not matter whether Always On Top is checked ON in this particular case.
The other exception to the ordering rule is when you have set an action group so that the Set Reading Order to Last is checked ON, as in Figure 3 of the Properties of the Next Button Action Group.
Figure 3 – Properties of an Action Group in Ribbon View, showing the Set Reading Order to Last property checked ON
Set Reading Order to Last is an Accessibility property for an Action Group that will ONLY been available IF you set the title to Use Web Accessibility Settings, as in Figure 4 in the Title Options of the title.
Figure 4 – Title Options showing the Use Web Accessibility Settings checkbox checked ON
Inside of the Next Button Action Group in the sample title, we have one object, which is, the Next button. Why would you want to do this? Well, when a visual person takes an eLearning course, he or she will read the content on a particular web page, listen to audio, watch a video, play a game, etc. and then they will click the Next button to go to the next page. A screen reader user wants to do exactly the same thing, which is, read the content and go to the next page. However, they are using screen reader software. The easiest way for a screen reader user to do this is to have everything in order on the html page, first the content of the web page and then the Next button. However, most Next buttons are placed in the title at the Title level, BEFORE the content begins. So, if you remember from before, the objects are placed on the html page at the title level first before the content on a page. So, when the html is generated by Lectora, the order will be reverse from what we want, with the Next button read first by the screen reader and then the content of the web page. Before Lectora had this Set Reading Order to Last option, we would have had to add a Next button to EVERY page in a title after the web page content to achieve the order we wanted. With the Set Reading Order to Last option, we can force anything in this action group to come after the web page content. So, as a rule of thumb, we always create a Next Button Action Group at the title level, place a Next button inside of the Next Button Action Group and turn ON the checkbox for Set Reading Order for Last for the action group.
Joe Payne is a Web Application Architect who has been developing software in Microsoft development environments for almost 25 years. He has worked in state government for 14 years developing web solutions and has obtained a vast knowledge in Accessibility programming with Section 508 and WCAG 2.0 standards. He has developed eLearning solutions in Lectora for 7 years, including external HTML, CSS, and JavaScript extensions to resolve various web accessibility issues, and has created accessible Lectora templates. He can be reached on LinkedIn at Joe Payne.