Testing on 7.4.0 (2480)

I ran across a few small issues while testing Voice Over on Diffs:

• It is sometimes difficult to scroll the page with the 3 fingers gesture depending on where the user has focused last. Once the user has scrolled down the page it is difficult to scroll back up.
• Cannot expand an edit line, tapping the down arrow does not open the edit details.
• Cannot tap the text of an edit and have it read back.

Not a blocker for 7.4.0

I’m wondering if the experience can be as close as possible to the visual design, e.g. for the example in the above design, the reader outputs:

Line 9

The '''polar bear''' (''''Ursus maritimus'''') is a removal [[Hypercarnivore]] removal end addition hypercarnivore addition end |hypercarnivorous]] [[species]] of [[bear]].

In the Diff output, it’ll be important that the screen reader outputs it like code (literal reading, e.g. special characters, capitalization, indentation, line breaks, etc.).

Also, tagging our design accessibility expert @Volker_E – Do you have some guidance/tips regarding improving the screen reader experience for the Diff output (move/add/remove)? It’ll be great to consider these for @Mazevedo’s work!

Thanks! ⭐

Hi @scblr, can we get some more voice over design details on this one? We need to make the content area of the diff view accessible with Voice Over. A good start would be:

1. What the contextual expand arrows should speak when they are collapsed and expanded.
2. What it should say when it reads the contextual lines. Should it say something about it being an unchanged contextual line (which sighted users already have a hint at with the gray background)?
3. How it should speak actual changed lines (you already addressed this in the comment above, just want to confirm if you're good with us to move forward on your proposal).
4. How it should it read the "Paragraph moved" cells?

@Dmantena Feel free to chime in if I missed any good questions. Thx!

@Tsevener I’ll check in with Volker this week 👍

I talked to @Volker_E today – he will answer @Tsevener’s questions in T343582#9401664 in the upcoming days.

Ok, I did some research @Tsevener @Mazevedo. Please chime in @Volker_E if you skim this and see something you would do differently.

1. What the contextual expand arrows should speak when they are collapsed and expanded.

When the section is collapsed, it should announce "expand" to indicate that the content is currently hidden and can be expanded. When the section/arrow is expanded, the voice over should indicate it by saying "collapse" suggesting that the content is visible and can be hidden.

2. What it should say when it reads the contextual lines. Should it say something about it being an unchanged contextual line (which sighted users already have a hint at with the gray background)?

As you pointed out, it should announce "contextual line, unchanged" before reading. Users who rely on screen readers will then know that these lines are part of the surrounding context and aren’t modified. It replaces the visual cue of a grey background, providing a similar level of understanding.

How it should speak actual changed lines (you already addressed this in the comment above, just want to confirm if you're good with us to move forward on your proposal).

The voice over should announce "line added" for newly added lines and "line removed" for deleted lines. It enables users relying on screen readers to understand how the text was changed, mirroring the information sighted users would derive visually (red or green color + bold.)

For reading the actual code, let’s go with the inputs from T343582#9113369: "In the Diff output, it’ll be important that the voice over reads it like code (literal reading, e.g. special characters, capitalization, indentation, line breaks, etc).

How it should it read the "Paragraph moved" cells?

Question: I’m slightly confused by this 👇

• Does a) mean: 2 paragraphs have been moved down by 3 lines?
• Does b) mean: 2 lines have been moved up by 2 lines?

If yes, voice over should state:

• For a) "[number of paragraphs] paragraph(s) moved up [number of lines] line(s)" or "[number of paragraphs] paragraph(s) moved down [number of lines] line(s)"
• For b) "[number of lines] line(s) moved up [number of lines] line(s)" or "[number of lines] line(s) moved down [number of lines] line(s)"

Both will help to understand the direction and magnitude of the line movement.

@scblr

The voice over should announce "line added" for newly added lines and "line removed" for deleted lines.

Sounds good, I think we do have knowledge of whether or not a whole line has been added or deleted without a lot of extra processing work. What about when individual characters within the same line have been added or deleted?

Question: I’m slightly confused by this 👇

The original design is T234930 - note "If more than 1 section of text has been moved, each section is numbered"

So I think this means:

a) There have been two paragraphs so far that have been moved. This is a OLD spot of the 2nd paragraph move.
b) This is the NEW spot of the 2nd paragraph move.

Note that paragraphs can be moved across lines in the same section or across sections. So you could see something like "Paragraph moved up 2 lines" or "Paragraph moved up 2 sections".

@scblr

FYI here is your revision on mobile web - https://en.m.wikipedia.org/wiki/Special:MobileDiff/1183222933.

Keep in mind that every paragraph move displays things as a pair - the old spot and the new spot. I'm 99% sure that orange "2" after the arrow is supposed to serve more like an identifier for the pair here. It's a little easier to lose track of which paragraph callouts are a part of the same pair without it.

In T343582#9445943, @Tsevener wrote:

@scblr

The voice over should announce "line added" for newly added lines and "line removed" for deleted lines.

Sounds good, I think we do have knowledge of whether or not a whole line has been added or deleted without a lot of extra processing work. What about when individual characters within the same line have been added or deleted?

A more robust way to handle all cases (line added, line removed, individual characters within the same line) is to output: "content added" and "content removed". It’d be also in sync with the titles used on Mobile Web.

Thoughts?

Question: I’m slightly confused by this 👇

The original design is T234930 - note "If more than 1 section of text has been moved, each section is numbered"

So I think this means:

a) There have been two paragraphs so far that have been moved. This is a OLD spot of the 2nd paragraph move.
b) This is the NEW spot of the 2nd paragraph move.

Note that paragraphs can be moved across lines in the same section or across sections. So you could see something like "Paragraph moved up 2 lines" or "Paragraph moved up 2 sections".

Ok, thanks, I got it! I assume it’s important for visually impaired users to easily switch back and forth between moved paragraphs. Therefore my suggestion is:

a) Paragraph moved up/down [number of lines] line(s). Go to new location.
b) Paragraph moved. Go to previous location.

Works with sections too:

a) Paragraph moved up/down [number of sections] section(s). Go to new location.
b) Paragraph moved. Go to previous location.

In T343582#9445041, @scblr wrote:

Ok, I did some research @Tsevener @Mazevedo. Please chime in @Volker_E if you skim this and see something you would do differently.

1. What the contextual expand arrows should speak when they are collapsed and expanded.

When the section is collapsed, it should announce "expand" to indicate that the content is currently hidden and can be expanded. When the section/arrow is expanded, the voice over should indicate it by saying "collapse" suggesting that the content is visible and can be hidden.

Correct. Additional to the context. So “Expand [title of section to be expanded]“

2. What it should say when it reads the contextual lines. Should it say something about it being an unchanged contextual line (which sighted users already have a hint at with the gray background)?

As you pointed out, it should announce "contextual line, unchanged" before reading. Users who rely on screen readers will then know that these lines are part of the surrounding context and aren’t modified. It replaces the visual cue of a grey background, providing a similar level of understanding.

I'm missing context, when is it a "contextual line, unchanged". This could be an invitation to expose too much to screenreader users. Just clarifying here. Does it be exposed after a changed line, so users should know again, that it's unchanged from there on?

How it should speak actual changed lines (you already addressed this in the comment above, just want to confirm if you're good with us to move forward on your proposal).

The voice over should announce "line added" for newly added lines and "line removed" for deleted lines. It enables users relying on screen readers to understand how the text was changed, mirroring the information sighted users would derive visually (red or green color + bold.)

For reading the actual code, let’s go with the inputs from T343582#9113369: "In the Diff output, it’ll be important that the voice over reads it like code (literal reading, e.g. special characters, capitalization, indentation, line breaks, etc).

How it should it read the "Paragraph moved" cells?

Question: I’m slightly confused by this 👇

• Does a) mean: 2 paragraphs have been moved down by 3 lines?
• Does b) mean: 2 lines have been moved up by 2 lines?

If yes, voice over should state:

• For a) "[number of paragraphs] paragraph(s) moved up [number of lines] line(s)" or "[number of paragraphs] paragraph(s) moved down [number of lines] line(s)"
• For b) "[number of lines] line(s) moved up [number of lines] line(s)" or "[number of lines] line(s) moved down [number of lines] line(s)"

Both will help to understand the direction and magnitude of the line movement.

A more robust way to handle all cases (line added, line removed, individual characters within the same line) is to output: "content added" and "content removed". It’d be also in sync with the titles used on Mobile Web.

Agreed!

Thanks @Volker_E for taking the time to answer!

2. What it should say when it reads the contextual lines. Should it say something about it being an unchanged contextual line (which sighted users already have a hint at with the gray background)?

As you pointed out, it should announce "contextual line, unchanged" before reading. Users who rely on screen readers will then know that these lines are part of the surrounding context and aren’t modified. It replaces the visual cue of a grey background, providing a similar level of understanding.

I'm missing context, when is it a "contextual line, unchanged". This could be an invitation to expose too much to screenreader users. Just clarifying here. Does it be exposed after a changed line, so users should know again, that it's unchanged from there on?

Here’s an example of contextual lines:

Default	Expanded

They’re used to "save" vertical screen space in a diff on iOS. They are shown before and after the actual edit/change to provide context. Here’s the same diff equivalent on Mobile Web for comparison.

Per discussion yesterday @Tsevener, here’s the summary of the previous conversation that I’ll add to the task’s description:

1. What the contextual expand arrows should speak when they are collapsed and expanded.

• When the section is collapsed, the voice-over should announce Expand line x to y
• When the section is expanded, the voice-over should announce Collapse line x to y

2. What it should say when it reads the contextual lines.

Voice-over should announce Contextual line, unchanged before reading the contents.

3. How it should speak actual changed lines

Voice-over should announce Content added and Content removed before reading the contents.

4. How it should it read the "Paragraph moved" cells?

For lines, the voice-over should announce:

a) Paragraph moved up/down [number of lines] line(s). Go to new location.
b) Paragraph moved. Go to previous location.

For sections, the voice-over should announce:

a) Paragraph moved up/down [number of sections] section(s). Go to new location.
b) Paragraph moved. Go to previous location.

Estimation notes: There is some work from diffs that we might be able to reuse. Some code to sift through.

@JTannerWMF Updated bottom of description with breakdown of complete and remaining engineering tasks to conclude this task.

Partial PR: https://github.com/wikimedia/wikipedia-ios/pull/4764

Partial PR: https://github.com/wikimedia/wikipedia-ios/pull/4771

Very much improved on 7.4.10 (3385)