Thread Subject: Re: Group B: 21(h) animations
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Langum, Michael J
Date: Fri, Nov 17 2006 12:00 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Gregg Vanderheiden: "Re: Group B: 21(h) animations"
- Previous message in thread: Gregg Vanderheiden: "Re: Group B: 21(h) animations"
- Messages sorted by: Author | Thread | Date
[Dewi wrote] "The progress indicator is not an animation. This is a control. If you want the screen reader to read this out to you, you need to set the right focus to this control. Why is this considered as animation?"
[JT wrote] "We have a terminology problem here. At the coding level, a progress indicator is a control. At the user interface level [...]it is an animation, ...."
I may be naÃ¯ve about the "control/animation" distinction. Is it possible that, in the case of a "control," it would be possible (at least in principle) to expose to AT a non-visual "progress" indicator (e.g. numeric percent complete, or time remaining value).
Could we suggest that progress "controls" (or more generally, any "graphical-output control") should expose a numerical value (along with the units [e.g. percent, KB downloaded, seconds, etc.].
[Allen Hoffman wrote] "My experience is that they have and can cause disruption to assistive technologies."
Lacking experience, I ask -- In what way does a progress animation (or control) for that matter disrupt AT?
- Next message in Thread: Gregg Vanderheiden: "Re: Group B: 21(h) animations"
- Previous message in Thread: Gregg Vanderheiden: "Re: Group B: 21(h) animations"