Current best practices for representing text edits in a screen reader?...

Joseph Scheuhammer clown at alum.mit.edu
Wed Oct 25 14:38:57 UTC 2017


Hi Tony,

Thanks for the explanation.  I now see what the main issue is, and what
it isn't:  It's not a case of dynamic changes of content that should be
relayed by an AT.  It is the presentation of static differences.  As
such, the live region machinery that I referenced in my previous email
is not appropriate.

To a first approximation, I would describe the situation as follows: 
There is a unit of difference that has two parts, and the two parts are
related by a "before/after" or "added/removed" relationship. I think
this relationship is important, perhaps key; that there are not merely
two regions of text, but the nature of the relationship between them. 
That's what the colours and "+/-" are cuing visually.  Using Github's
way of rendering the differences -- it's slightly different but similar
when using 'git diff' on the command line -- the replacement/after text
has a green background with "+" characters to indicate additions, and
the removed/before text has a red background and uses "-" for removals. 
And, the two chunks of text are spatially close, either one above the
other, or side-by-side, indicating they are a pair. The colours,
characters , and spatial proximity visually communicate the relationship.

Some accessibility APIs support relationships.  Unfortunately, there
isn't anything for "before/after", or anything that is close  Perhaps
it's something that needs to be added:
http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/group__grp_relations.html
https://developer.gnome.org/atk/stable/AtkRelation.html#AtkRelationType

Having a useful representation of the diff is one aspect of the overall
problem.  That's where markup, ARIA, and accessibility APIs have a role,
and that's where my expertise lies.  The other aspect is how an AT, such
as a screen reader, presents that representation.  That is a UX issue,
and that's not really my forte.  Also, different screen readers likely
render the situation differently.  You've outlined your experience with
VO -- what happens with JAWS, NVDA, ChromeVox, and/or Orca?  Is there a
rough interoperability?  I fear we are ahead of the curve here.

Regarding specifically the use of <del> and <ins> elements:  I looked up
how they are exposed by a11y APIs.  Most APIs lose the semantic aspect
of the elements (if there was any to begin with), and expose only the
stying.  The only API that creates a node in the accessibilty tree is
macOS's AX-API (the a11y API that VoiceOver uses).  It creates a "group"
role, but there is nothing to distinguish a "del" group from an "ins"
group.  At least I don't think there is.  Do you have a sample that I
could load into Safari and see what comes out in the a11y tree?  For
reference, here are the mappings for <del> and <ins>:
https://w3c.github.io/html-aam/#el-ins
https://w3c.github.io/html-aam/#el-del

Regarding using "content" in CSS, I am reluctant.  CSS is for styling;
the DOM is for content.  CSS content was intended for decorative
content.  Note that textual content added using CSS "content" rules
cannot be searched, nor selected, and does not behave like DOM content. 
It renders on screen, but it kinda/sorta acts like it isn't really
there.  On the other hand, if it works for your purpose, then perhaps it
is the way to go.  However, what is wrong with actually inserting the
text into the DOM?

Hope that's useful.


On 2017-10-24 4:01 AM, Tony Atkins wrote:
> Thanks, Joseph.
>
> In this case, I'm presenting something like the "diff" view in
> GitHub,  where unchanged content appears in white, additions in green,
> and deletions in red, all presented in order from the beginning to the
> end of the document.  All of the change events have already happened,
> and even if they hadn't, the key is that I want the changes to appear
> in context.  With my current mockup, for example, the sequence is as
> follows:
>
>  1. VO (VoiceOver) reads unchanged text within a paragraph without
>     interruptions.
>  2. VO stops reading when it reaches a <del> or <ins> tag.
>  3. I hit VO+right arrow to indicate that I want to continue reading. 
>     The "before" content is announced, as in "content added", and VO
>     stops.
>  4. I hit VO+right arrow again, the contents of the <del> or <ins> are
>     read, and VO stops again.
>  5. I have to hit VO+right arrow to read the next portion of the document.
>
> This seems like way too many interruptions to make sense of the
> changes in context.  What I'd like is for the changes to be announced
> as the text is read, as in:
>
>     This is the (content removed: first) (content added: second)
>     version of this sentence.
>
>
> Thoughts?
>
> Cheers,
>
>
> Tony
>
> P. S. I really appreciate the links, that's really good information. 
> Do you know of any sites that make good use of that type of change
> events?  I'd like to try them out with VoiceOver.
>
> P. P. S. UL is just short for Unified Listing.
>
> On 23 October 2017 at 22:05, Joseph Scheuhammer <clown at alum.mit.edu
> <mailto:clown at alum.mit.edu>> wrote:
>
>     Hi Tony,
>
>     I'm not sure this addresses your issues, since I don't know what
>     UL is, but, FWIW...
>
>     Perhaps using the live region ARIA attributes would help here. 
>     But, you shouldn't have to as browsers are supposed to emit
>     accessibility events for changes in document content:
>     https://www.w3.org/TR/core-aam-1.1/#mapping_events_visibility
>     <https://www.w3.org/TR/core-aam-1.1/#mapping_events_visibility>
>
>     Unfortunately, there is no guarantee that browsers are emitting
>     those events, nor, if they are, that ATs are listening for them. 
>     Judicious use of aria-live and its associates should force the issue.
>
>       * aria-live:  https://www.w3.org/TR/wai-aria-1.1/#aria-live
>         <https://www.w3.org/TR/wai-aria-1.1/#aria-live>
>       * aria-relevant:
>         https://www.w3.org/TR/wai-aria-1.1/#aria-relevant
>         <https://www.w3.org/TR/wai-aria-1.1/#aria-relevant>
>       * aria-atomic: https://www.w3.org/TR/wai-aria-1.1/#aria-atomic
>         <https://www.w3.org/TR/wai-aria-1.1/#aria-atomic>
>       * aria-busy: https://www.w3.org/TR/wai-aria-1.1/#aria-busy
>         <https://www.w3.org/TR/wai-aria-1.1/#aria-busy>
>
>     Hope that helps.
>
>
>     On 2017-10-23 8:57 AM, Tony Atkins wrote:
>>     Hi, All:
>>
>>     In recent work on the UL, I have been trying to represent
>>     revisions to a document in a way that also makes sense with a
>>     screen reader.
>>
>>     I started by using /aria-label/ attribute to add hints like "this
>>     content was added" and "this content was removed".   At least
>>     with VoiceOver, this resulted in odd artefacts like announcing
>>     each change as a group containing two items.
>>
>>     I moved on to trying to use the HTML <ins> and <del> elements to
>>     enclose insertions and deletions respectively.  This made no
>>     difference at all in the way VoiceOver read the content.
>>
>>     I then updated this approach based on the strategy described here
>>     <http://pauljadam.com/demos/css-line-through-del-ins-accessibility.html> under
>>     "CSS Generated Content + Visually Clipped Text", which is to add
>>     visually-clipped content before <ins> and <del> elements using
>>     something like the following HTML and CSS snippets:
>>
>>         This string <del>is unchanged</del> <ins>has been updated</ins>.
>>
>>         ins:before {
>>             content: "content added:";
>>             position: absolute;
>>             clip: rect(0 0 0 0);
>>         }
>>
>>         del:before {
>>             content: "content removed:";
>>             position: absolute;
>>             clip: rect(0 0 0 0);
>>         }
>>
>>     In my limited testing with VoiceOver, this requires more effort
>>     on the user's part to move through the content, as the screen
>>     reader stops on each before as well as each element.  However,
>>     the text read aloud is clear and does not add odd "group"
>>     announcements like the "labeled-by" strategy.
>>
>>     I was hoping to get some input from the wider group, as I know
>>     very many of you are quite knowledgeable in this area, and have
>>     experience with a wider range of screen readers as well.  Any
>>     ideas or pointers to previous work in this area would be appreciated.
>>
>>     Thanks,
>>
>>
>>     Tony
>
>
>     -- 
>     ;;;;joseph.
>
>     'Call me hobophobic, but I don't think two vagrants should be allowed to marry.'
>                                    - J. Tiedrich -
>
>
>     _______________________________________________________
>     fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
>     <mailto:fluid-work at lists.idrc.ocad.ca>
>     To unsubscribe, change settings or access archives,
>     see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>     <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
>
>

-- 
;;;;joseph.

'Call me hobophobic, but I don't think two vagrants should be allowed to marry.'
                               - J. Tiedrich -



More information about the fluid-work mailing list