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

Tony Atkins tony at raisingthefloor.org
Tue Oct 24 08:01:55 UTC 2017


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> 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
>
> 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
>    - 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
>    - 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
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20171024/21f2e6eb/attachment.html>


More information about the fluid-work mailing list