WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: single page app with language switching button

for

From: glen walker
Date: Oct 2, 2020 9:28AM

Steve's enthusiasm is always appreciated but just to lessen some of the
"harshness" most developers are not intentionally making websites
inaccessible. Most inaccessibility comes from ignorance of accessibility
principles or semantic html.

I'm not sure it's clear in the spec what should happen if you change the
language of the page (specified on the main <html> element). If a screen
screen reader does not update its buffer, is it an html developer's fault?
Usually "fault" doesn't matter when you're concerned with the user
experience. There are lots of accessibility issues caused by various
browser/screen reader combinations. They can often be coded around to make
the experience better. Some companies choose to work around the issue
making the experience better for the user but other companies choose to
stick with their technically correct code and wait for the browser or
screen reader to fix the problem. There are merits for both. For the
user, the former is obviously better but if we always code around problems,
sometimes the real underlying problem is never fixed. And if you code
around the problem and the browser and/or screen reader fixes the issue at
some point, sometimes the code around isn't as good as the resulting fix
and now you have to remember to back out the code change.

In this specific scenario, personally, I would verify the problem exists
with JAWS, NVDA, VoiceOver (Mac and iOS), and Talkback. Sounds like you
checked JAWS and NVDA. Then I would check the community forum for each of
those to see if anyone else has had this issue (kind of like you're doing
by posting here on WebAIM, but I would check the JAWS forum specifically,
and the NVDA forum specifically, etc). Then I would try to contact the
official support for each to see if they know about the problem. It might
be a simple fix on their end to flush the buffer when the language
changes. Who knows? And then as Steve mentioned, I would play with some
workarounds to force the page to reload. You could have a note with the
switch that says the page will "reload and possibly flash" when you switch
languages. Having the note visible and programmatically associated with
the switch would be ideal.


On Thu, Oct 1, 2020 at 12:39 PM Steve Green < <EMAIL REMOVED> >
wrote:

> I would say that you need to refresh the page, even if you don't want to.
> I know that one of the whole points of a single-page application is to
> avoid reloading pages, but this is a choice and it is completely
> unnecessary. You broke it, so you fix it. It's not as if people will be
> changing language very often, so it doesn't matter if the page reload takes
> a few seconds and looks a bit clunky.
>
> I don't know if it would even be possible for you to force assistive
> technologies to refresh their virtual buffer or whatever else would be
> required to change the synthesizer language, but it seems like bad manners
> even if you can.
>
> Sorry if this seems a bit harsh, but I am heartily sick of bad development
> choices manifesting themselves as accessibility problems, and then we're
> the bad guys for asking the developers to fix them. The use of a
> single-page application is never essential. It's a choice and it has
> consequences.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
>