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

Tony Atkins tony at raisingthefloor.org
Wed Oct 25 15:25:40 UTC 2017


Thanks, Joseph:

When I sent this to the list, I was specifically hoping to hear from you,
and you haven't disappointed... ;)

I have spent much of the day trying out a range of browsers in combination
with VoiceOver and NVDA.   For that purpose, I packaged up a "canned"
version of the content rendered by my templates, which you can see here:

http://the-t-in-rtf.github.io/diff-demo/20171024.html

This is close to the approach I outlined yesterday, although I tidied up
the whitespace considerably today, which seemed to help the rhythm of the
spoken text.  I also added "after" text to indicate the end of the change.

In short, my current approach works well in Chrome with either NVDA or
VoiceOver, in that all the announcements added using CSS are announced at
the right time.  The approach does not work at all with Firefox on either
platform.  None of the CSS announcements are spoken.

I think I'll build on your suggestion and add text that is hidden but not
aria-hidden, to see if that works better with Firefox.  I'll send a link to
the updated work once I have it.

Cheers,



Tony

On 25 October 2017 at 16:38, Joseph Scheuhammer <clown at alum.mit.edu> wrote:

> 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-access
> ibility.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 -
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20171025/bada308b/attachment.html>


More information about the fluid-work mailing list