Readers skipping and omitting content follow-up

web-foley

Hello,

From the recent LAUG conference call (Aug 27, 2020) I promised I'd throw together a sample of a Lectora 18 course I'm getting anomalies with in a JAWS reader.

I've attached a Word document in the attached zip file (along with the awt) that details more specifics, but in short, I'm wondering if someone can test a publish in Lectora 19 to see if these show up.

As I mentioned on the call, one of the things I noticed is that when I do an HTML publish and Preview directly from the Publish prompt (rather than, let's say opening a001_welcome.html in a Chrome browser), this is when most things do NOT read correctly in JAWS (skipping content on the page, or usually just omitting it entirely).

Since I will ultimately be publishing for SCORM 1.2 (and this would default require/select the Include Title Frame Manager) it is the more accurate setting for replicating my issues while viewing on the clients LMS. But this seems to be the biggest issue as it's messing up the Screen Reader.

Suggestions or findings from a Lectora 19 publish?
Thanks,

Darrell.

 

tea

Hey @Web-Foley I was on the LAUG yesterday. Thanks for the file! I'll give this a try with v19 and see how JAWS reads it locally and when published to our server.

tea

@Web-Foley with v19 the first page was read ok for me, and I also heard the MC question and choices correctly.

I am seeing some of the other pages missing the reading as you described. I have a bug open to track this, but maybe someone from the LAUG may have some suggestions

prg1792

Hi, @web-foley

I'm not a JAWS expert, but I do have some tips for reading content. I've downloaded your sample, ran it in a localhost, and read it with JAWS 19 and NVDA. Both read all of the content, although I do not use auto read. Instead, I step through each component from the top. I have found this to be the most reliable way to read a Lectora page, probably because it is drawn dynamically and screen readers may start reading content in the middle of the page instead of from the top.

In JAWS, when a page loads, I hit CTRL+HOME to go to the top of the current page. Then, I use the P key to step through each paragraph/component. This reads each heading, button, text item individually which allows me to confirm the proper reading order. For forms (questions), I might also use arrow keys or TAB to step through radio buttons or checkboxes, respectively. For NVDA, I use CTRL+HOME to go to the top of the page, then the DOWN ARROW key to step through the objects in the same way.

The only "issue" I had was the hidden text that appears, like on P03, was read twice. I read the "One" button and activated it by hitting Enter. The text appeared and was immediately read by JAWS because it is aria-live:polite, which means it will be read by the screen reader when it is displayed once nothing else is being read. Then when I hit P to advance to the next object, it read the text again, this time because it was in the sequence of page objects. Not unexpected given the aria tag.

Hope this information helps!

web-foley

Thanks Ann, @prg1792

I appreciate you adding some new JAWS/NVDA tips to the brain vault. I also noticed that ensuring each page having an H1 tag also helped 'force' the reader to start at a heading... but only sometimes. Also, "h" was a good hot-key in JAWS to jump to the first header.

This is something I hope to discuss soon with Lectora developers, when I did add an H1 title to every page it solved the reading order when I Published to HTML (and passed it to colleagues with a JAWS reader), yet with no other changes, when I Published to SCORM and promoted to our LMS it continued to be messed up. I don't know enough about it to identify the intricacies of how Lectora renders a basic HTML publish versus the SCORM publish, or why one would read more accurately than the other.

-Darrell

prg1792

Hi, @web-foley

From what I have seen with published Lectora content, the HTML page is the same whether published for SCORM or just web. The only difference is that the HTML page is in a frameset when published as SCORM. So nothing about the reading order changes between the two publishing methods.

It seems that what you are experiencing is not a difference in reading order (the actual order of the objects on the HTML page), but where in that order the screen reader starts reading. Try using CTRL+HOME to start reading the page from the top instead of allowing the screen reader to start at some random point. Then you will be able to walk through the objects on the page and verify they are in the order you want, regardless of SCORM or web publish.