Re: accessible name computation & changing button labels

I agree with Patrick that this is conformant as-is, and I'll add my
observation of desktop screen reader users' micro interactions with such
buttons.

(1) A user activates the button. (2) Nothing is immediately announced, so
they wait... not seeing the screen, they initially assume it might be
processing. (3) After a few seconds, they want to know what has happened
and where they are now, so they announce their current location, e.g.
Insert+Tab.

Announcing the current focused element reliably announces the new button
name, so I do not recommend hacks to force an announcement in this case.

My observations on this have only been from guerilla research, so if
anybody has another perspective, please share. For example, I'm curious if
mobile screen reader users might swipe forward and back at step 3. I'm also
curious how context and button text affect users' initial expectations and
behaviors over time.

Cheers,
Mitchell

Mitchell Evan, CPWA
linkedin.com/in/mitchellrevan
Twitter @mitchellrevan
+49 1525 8950540
+1 510 375 6104

On Wed, Oct 14, 2020, 9:17 AM Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 14/10/2020 07:59, Adam Cooper wrote:
> > Hi all … working on a project at the moment with buttons whose label
> > changes when pressed .. can’t get a screen reader to announce the
> > changed label in situ (i.e., when focus remains on the button).
> >
> > Adding aria-live to the button or somewhere else on the screen just
> > seems like an ugly hack from yesteryear and it causes unnecessary
> > repetition.
> >
> > Just wondering, first, what the accessible name computation algorithm
> > says about this case or what the spec behaviour should  be, and, second,
> > whether anyone has any tips on how to resolve this?
>
> This seems to come down to different browser/AT combinations. The
> accname algorithm doesn't say anything about dynamic changes, and the
> approach is conceptually solid. Just that some browser/AT combos don't
> check/announce a dynamic change like that / bother to check.
> Unfortunately, this may indeed require some hacking like using a live
> region, or unfocusing and refocusing the control programmatically. Or
> putting it down to a browser/AT bug and not doing anything.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>