Prevent the reading of "dot" by keep periods together with text on a line

[terracoda]

In #74, @terracoda noticed (using Voice Over) that:

"dot" for period is read out if the period occurs on a line by itself. "Dot" is not read out when it occurs as part of a string of text on a line.

Possible general solution:

• make the invisible PDOM wider and further off screen?

Quick fix for this sim: For this sim, I simply removed the periods on the short list items in the State of the Sim section. So they now look like this:

"Right now,

• Voltage, V, is 4.5 volts
• Resistance, R, is 500 ohms
• Current, I, is 9.0 milliamps"

Note that the reading of punctuation does vary between AT software and user verbosity settings. Further testing is likely required.

[jessegreenberg]

Thanks @terracoda. I also noticed that it reads each word individually. Reading through an item it sounds like "Bullet, bullet". "Voltage". "V" "is" "4.5 volts" "Period".

I am not sure if it is related to the width. When I read through the items in the copied DOM in http://www.colorado.edu/physics/phet/dev/html/ohms-law/1.4.0-dev.9/ohms-law-a11y-view.html it also sounds like this.

But when I read through http://htmlpreview.github.io/?https://github.com/phetsims/a11y-research/blob/master/html-sketches/ohms-law/ohms-law-pdom.html it reads through the whole line.

[jessegreenberg]

Does seem related to styling. If I remove position: absolute from the PDOM, the problem goes away. But then the sim is moved off screen to make room for the PDOM.

I also noticed that removing the formatting tags also makes the problem go away.

[terracoda]

@jessegreenberg, by formatting tags, you mean strong tags, right. What I like about the strong tags is that some screen readers read that text in a different pitch, making the letters in the equation stand out a little bit from the surrounding text.

Can you try putting the period inside the strong tag?

[jessegreenberg]

@terracoda for your VoiceOver does it read like each line individually like this: "Bullet, bullet". "Voltage". "V" "is" "4.5 volts" "Period".

Ill try but my guess is that it will still read it like "Bullet, bullet". "Voltage". "V" "is" "4.5 volts."

Where each line has to be read individually.

[terracoda]

I'll listen again, but that sounds accurate.

[terracoda]

Before, I did repeat mentions of "bullet", but I think I changed my VO verbosity settings.

Right now in version 9, when I read with the cursor keys I get:

Right now, list, 3 items bullet 1 of 3 Voltage, V is 4.5 volts period bullet 2 of 3 ... etc.

[terracoda]

In the pdom do you have the em elements around the parameters, and the strong elements around the letters, as I did in the PDOM sample?

I have no idea why the screen reader stops reading when it encounters an inline element, but I think that is what it is doing.

[terracoda]

I suggest removing the em elements, they were actually for show to highlight the potentially dynamic pieces of the phrases.

I actually like having the strong element around the letters because it makes them stand out to me (screen reader changes pitch, pauses, and even provides a tiny bleep depending on verbosity settings). However, we could be really choosy about where we need to highlight the letters. It would be good to get user feedback on best practices for inline formatting.

I think for the strong elements, it is useful to leave them in for now, for consistency.

[terracoda]

Screen reader behaviour is so erratic. When I use Ctrl+ Option + B in Voice Over to read from beginning, sometimes it reads from beginning and goes to end without stopping, and sometimes it stops after the the first list item. There must be a command to make VO "just continue reading", but I don't know what that is, yet.

[terracoda]

@jessegreenberg, just happenned to use the inspector to look at the list for a different reason and there seems to be hidden line breaks in the content. Could this be the problem?

[jessegreenberg]

I don't think so @terracoda, that is just how dev tools show innerHTML. If you take a look at your PDOM mockup, it looks the same.

[jessegreenberg]

If we take out the em, and put the period in the strong tag, I think it will sound like this:

list, 3 items
bullet, bullet 1 of 3
Voltage,
V
is 4.5 volts.

Definitely an improvement, but it would be nice to have a general fix so we can use formatting tags however we wish.

[jessegreenberg]

Hey, this looks promising: https://stackoverflow.com/questions/5232310/htmlcss-how-to-force-div-contents-to-stay-in-one-line

[jessegreenberg]

Just verified that NVDA also has this problem.

[jessegreenberg]

OK, so if I copy the body and sim and paste into a JSFiddle it reads just fine?? https://jsfiddle.net/1ocgtLrs/7/

[jessegreenberg]

And If I right click -> save the sim and run the downloaded version the problem isn't there at all. Do AT not like formatting tags added dynamically?

[jessegreenberg]

If I create these dynamically it reads just fine in a JSFiddle. https://jsfiddle.net/ej5nkm93/2/

[jessegreenberg]

Still reading fine here: https://jsfiddle.net/ej5nkm93/6/

[jessegreenberg]

Back to the CSS:

      SceneryStyle.addRule( '.accessibility * { position: absolute; left: 0; top: 0; width: 0; height: 0, clip: rect(0,0,0,0); }' );

If I remove position: absolute; it reads just fine.

[terracoda]

Brilliant. So you don't need to use scroll: nowrap?

[jessegreenberg]

It doesn't seem like it, but I am concerned that removing position: absolute will do weird things to the rendering of the sim. But I am not seeing anything in Firefox.

[jessegreenberg]

In the a11y-view, removing the positioning causes tab navigation to move shove the sim up (probably because the PDOM is now below the sim?). I believe it will do the same in Safari in the normal sim view.

[jessegreenberg]

I would like to discuss this problem at the next a11y meeting to see if anyone has ideas for how to fix this, and to discuss priority for continued investigation.

[terracoda]

That's a good idea, @jessegreenberg. There are different kinds of positioning techniques, so it would be good to know exactly what position absolute is doing. Absolutely-positioned content is taken out of the normal content flow, so removing that property, would put the PDOM content back in to the flow, and it would take up space.

[jessegreenberg]

Here are some more recommendations for how to make content 'invisible' but available to a screen reader: http://webaim.org/techniques/css/invisiblecontent/

[terracoda]

@jessegreenberg, I had a session today with a VO user. For this VO user, reading through the lists was a painful experience. I think this issue is somewhat high priority.

If we have trouble fixing the layout issue, then I we may need to keep the use of lists for structure to a minimum.

[jessegreenberg]

Understood. The problem isn't really with lists, right? The problem is how AT read styling markup in the PDOM like <strong> and <em>.

[terracoda]

Well, the bullets of the lists are also being spoken on their own line, so it is a problem for both inline elements like <em> and <strong> and the reading of list items.

[terracoda]

And when they are all together, it really sounds like a big mess.

[terracoda]

@jessegreenberg, it looks like I need to tweak some of the descriptions for this sim, especially the Scene Summary and the circuit, so I might need to reconsider the use of some of the lists. Is that a problem?

[jessegreenberg]

@mbarlow12 recommended to try overflow: hidden.

@zepumph recommended to set the height to be 100px, with overflow hidden so that there is some width for the content.

[zepumph]

We experienced good success with @mbarlow12's suggestion to use relative position and move the content way over to the left. Like this:

.accessibility * {
    position: relative;
    left: -161px;
    top: 0px;
    width: 236px;
    height: 0px; // still worked with this in, but won't refocus lower when tab navigating.
}

We want to make sure that the left is so far left that it will never show up on the screen.

We also found duplicate css for accessibility. One is from the accessibility class, and the other is added directly to the root accessibleInstance, where that accessibility class is added.

@mbarlow12 has a few more ideas about the css, assigning to him for experimentation.

[terracoda]

@jessegreenberg, @zepumph , @mbarlow12 using relative positioning keeps things in the flow. Negative margins also keep things in the flow. Have you tried taking things way off screen with a larger values more like left:-10000. For a negative margin it would look like this margin-left: 1000em.

For testing I would simplify the CSS and see how far you get with just playing with left positioning or left margins. Once that is working you can see if you need to play with other properties (height, width, top, etc.)

Here are a couple articles on understanding positioning and negative margins. They are a bit old, but I think they are still relevant. I'm not sure what css3 effects there are on positioning and margins.

• https://css-tricks.com/almanac/properties/p/position/
• https://www.smashingmagazine.com/2009/07/the-definitive-guide-to-using-negative-margins/

[zepumph]

That looks just like what we were experimenting with! @mbarlow12 said that he would take a look, I would correspond with him.

[terracoda]

@zepumph, ok cool. I was just pointing out the possible use of negative margins.

[jessegreenberg]

I made an issue to investigate this in scenery since it applies to all sims and will be fixed there. I moved notes and progress to that issue for continued work. Closing.