E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Mike Warner
Date: Fri, Oct 29 2021 9:10AM
Subject: fade-in text abd auto-navigation to next slide
No previous message | Next message →

Hi all,

I'm evaluating a course created in Articulate that has text that gradually
fades in, usually from top to bottom, but not always. The material also
automatically proceeds to the next slide after the voiceover completes.

Before the fade-in text is visible, it's not available to AT. As such,
some AT users won't know that the text will appear eventually and, if they
can't hear the voiceover, they won't know that they're missing content.
The AT sees an empty slide when it loads and arrowing or tabbing gives
nothing to announce. I'm trying to figure out which WCAG item this would
fail, but am not really sure. Maybe it's just a poor design? They seem
rather stuck on having the text fade-in this way. There are ways for
fade-in text to be available to AT before it's visible, but I'd like to
point to a WCAG item for reference and back-up.

The material also auto-navigates to the next slide when the voiceover is
done. You can pause the audio to prevent this, but then you won't hear all
of the spoken text and the fade-in text will stop fading in. I'm thinking
that this is an issue for 2.2.1 – Timing Adjustable, but am not positive.
Is it?

Thank you,
Mike

Mike Warner
Director of IT Services
MindEdge, Inc.

From: glen walker
Date: Fri, Oct 29 2021 4:26PM
Subject: Re: fade-in text abd auto-navigation to next slide
← Previous message | No next message

I try not to limit what the designers want to do and work with them to make
their concept accessible. Personally, I'd rather see all the text rather
than having it fade in. The timing of the fade might be too slow for my
taste, or if it's too fast it could be distracting from me reading the
content. But if that's what they want to do, we can try to make it
accessible.

*Not* being able to read the text with assistive tech while the text is
visible (albeit partially faded) could be a 1.3.1 or 1.3.2 issue. Take
your pick. As long as it's an accessibility issue, it doesn't really
matter which one you use.

As far as the speed of the fade-in, that could be 2.2.1 or 2.2.2. If the
fading lasts longer than 5 seconds, then it's a 2.2.2 issue, sort of.
2.2.2 specifically points out "Moving, blinking, scrolling" content.
Content that fades in isn't really moving, blinking, or scrolling so
someone might nitpick that 2.2.2 doesn't apply. But 2.2.1 could equally
apply. 2.2.1 talks about a "time limit" and has a note that says "This
success criterion helps ensure that users can complete tasks without
unexpected changes in content or context that are a result of a time
limit." Again, someone might argue that text fading in isn't a "change of
content" but that would be a stretch argument. I think it applies.

You could even go so far as to say 1.4.3 applies because before the text is
fully faded in, it probably has insufficient contrast.

The higher view here is to make it as accessible as possible to everyone
and to not nit pick which success criterion (or criteria) it fails. I think
you have plenty of failures to choose from.

All the issues could be avoided if you had a simple "allow text fading" or
"allow animations" option.