Re: Question about restitution of aria-describedby

Let's reason this one out to understand why this one might be confusing. In
practical terms (ignoring any nuances in written specifications), it is
clear that if we give a displayed component a text description, but then
hide that description in some way, we are basically giving contradictory
instructions, are we not? We are instructing AT to announce a text that we
have also hidden to stop it being announced! It's a case of GIGO (garbage
in, garbage out).

But it was on the cards that developers would do things like this, so
screen reader creators and spec writers had to decide how to handle it when
the occasion arose. We can see why the AT (and seemingly the specs as well)
decide to announce hidden text (as already explained in this thread),
because - surely - the component will always need the description when it
is displayed, regardless of the state of the text being used for the
description! So we can't really complain about their solution - if we give
unclear, contradictory instructions, we must take the consequences! The
only fly in the ointment is that not necessarily all of the lesser known AT
devices are guaranteed to follow the same solution as the mainstream ones
(and like someone else in this thread, I also seem to remember that one of
the mainstream readers (possibly VoiceOver?) doesn't apply the same
solution).

The answer to this problem, which will avoid all confusion, is for
developers to use a solution that is clear and non-contradictory. They
should use a text that is not hidden at any time. They can, for instance,
use the long and well established method of adding text in the HTML but
hiding it from view visually using the usual CSS method of 1px font sizes
with clipping etc (we all know the method for hiding text for AT only).

And to meet the needs of developers who want the text description to change
in various circumstances, they can use JavaScript to change the text they
are using as required as already described by Marc below.