Thread Subject: Auto-updating
Note
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.
Return to this mailing list's archives
From: Jared Smith
Date: Tue, Aug 14 2007 3:45 PM
Subject: Auto-updating
I was tasked with looking at the use and definition of "auto-updating"
in the Pausing provision. The purpose of this provision, if I
understand correctly, is only for visual reading and cognitive
comprehension of changing or moving elements
(http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20070730/time-limits-pause.html).
There are mechanisms for presenting updating content to AT in an
accessible way (particularly with WAI-ARIA's live regions) and we do
not want to limit these technologies by effecting this pause provision
upon them. This term could also be interpreted to include things like
audio, which are covered elsewhere.
The difficulty then, is identifying what types of auto-updating
content might interfere with reading and comprehension, because
certainly some does not. The difference seems to be mostly in the
frequency of the changes - a text box that updates every second poses
a problem, but does a status indicator that changes every hour make
the page inaccessible? (Besides, adding a play/pause control would
likely make it *less* accessible.)
Seeing as it will likely be impossible to identify a threshold for
frequency of changes, I have two possible recommendations:
OPTION 1:
Remove the word 'auto-updating' entirely.
OPTION 2:
Replace 'auto-updating' with 'continually changing' or 'constantly
changing' or some other measure that indicates it happens often enough
to be a problem.
Thoughts?
Jared Smith
From: Jared Smith
Date: Wed, Aug 15 2007 1:30 PM
Subject: Re: Auto-updating
Again, I'm just capturing some issues and thoughts from today's call
to spur discussion.
- I have concerns that 'auto-updating' is overly expansive as it may
include areas of screen reader accessibility that can be addressed, at
least partially, using existing techniques and WAI-ARIA.
- It appears that the intention of this in WCAG 2.0 is *not* for
screen readers at all -
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20070730/time-limits-pause.html
- but we seem to agree that auto-updating does expand it's
applicability to screen readers.
- The definition of 'auto-updating' provided by Sean and Andi -
http://teitac.org/wiki/Web_and_Software:_Definitions#In_process_definitions
- *mostly* addresses these issues by limiting it to visual changes.
Here is what I would recommend:
"A mechanism must be provided to pause information that moves, blinks,
scrolls, animates, or changes visually for more than three seconds
and/or repeatedly over time unless it is part of an activity where
timing or movement is essential. A mechanism must be provided to stop
or hide moving content that is pure decoration."
Note: Moving or changing content may also introduce issues for screen
readers. Techniques, such as WAI-ARIA live regions, for limiting
screen reader interference should be implemented when appropriate.
* This reintroduces the 3 second buffer to allow visual cues to draw
cognitive focus to relevant content.
* It replaces 'auto-updating' with 'changes visually repeatedly over
time'. This addresses my concerns and is much better than "continually
changing". It also removes the need for a definition. 'Over time' may
need additional clarification, though I'm not sure how to define a
threshold.
* The note addresses screen reader issues. It could certainly be expanded.
* Clarifies that animation is included.
* Adds the option to hide decorative stuff.
Jared Smith
On 8/14/07, Jared Smith wrote:
>
> Seeing as it will likely be impossible to identify a threshold for
> frequency of changes, I have two possible recommendations:
>
> OPTION 1:
> Remove the word 'auto-updating' entirely.
>
> OPTION 2:
> Replace 'auto-updating' with 'continually changing' or 'constantly
> changing' or some other measure that indicates it happens often enough
> to be a problem.
From: Peter Wallack
Date: Wed, Aug 15 2007 7:15 PM
Subject: Re: Auto-updating
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
There's something about only allowing one solution, pausing, that
bothers me - how
about if we also allow changing the rate as an option? Also, don't we
want the
provision for decoration to include blinking, scrolling , and animating
content in addition to moving content? Put all together, that could
look like:<br>
<br>
<pre wrap="">"A mechanism must be provided to pause or change the rate that information moves, blinks,
scrolls, animates, or changes visually for more than three seconds
and/or repeatedly over time unless it is part of an activity where
timing or movement is essential. A mechanism must be provided to stop such content when it
is pure decoration."</pre>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
<br>
<br>
Jared Smith wrote:
<blockquote
cite="mid: = EMAIL ADDRESS REMOVED = "
type="cite">
<pre wrap="">Again, I'm just capturing some issues and thoughts from today's call
to spur discussion.
- I have concerns that 'auto-updating' is overly expansive as it may
include areas of screen reader accessibility that can be addressed, at
least partially, using existing techniques and WAI-ARIA.
- It appears that the intention of this in WCAG 2.0 is *not* for
screen readers at all -
<a class="moz-txt-link-freetext" href="http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20070730/time-limits-pause.html">http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20070730/time-limits-pause.html</a>
- but we seem to agree that auto-updating does expand it's
applicability to screen readers.
- The definition of 'auto-updating' provided by Sean and Andi -
<a class="moz-txt-link-freetext" href="http://teitac.org/wiki/Web_and_Software:_Definitions#In_process_definitions">http://teitac.org/wiki/Web_and_Software:_Definitions#In_process_definitions</a>
- *mostly* addresses these issues by limiting it to visual changes.
Here is what I would recommend:
"A mechanism must be provided to pause information that moves, blinks,
scrolls, animates, or changes visually for more than three seconds
and/or repeatedly over time unless it is part of an activity where
timing or movement is essential. A mechanism must be provided to stop
or hide moving content that is pure decoration."
Note: Moving or changing content may also introduce issues for screen
readers. Techniques, such as WAI-ARIA live regions, for limiting
screen reader interference should be implemented when appropriate.
* This reintroduces the 3 second buffer to allow visual cues to draw
cognitive focus to relevant content.
* It replaces 'auto-updating' with 'changes visually repeatedly over
time'. This addresses my concerns and is much better than "continually
changing". It also removes the need for a definition. 'Over time' may
need additional clarification, though I'm not sure how to define a
threshold.
* The note addresses screen reader issues. It could certainly be expanded.
* Clarifies that animation is included.
* Adds the option to hide decorative stuff.
Jared Smith
On 8/14/07, Jared Smith wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Seeing as it will likely be impossible to identify a threshold for
frequency of changes, I have two possible recommendations:
OPTION 1:
Remove the word 'auto-updating' entirely.
OPTION 2:
Replace 'auto-updating' with 'continually changing' or 'constantly
changing' or some other measure that indicates it happens often enough
to be a problem.
</pre>
</blockquote>
<pre wrap=""><!---->
WebAIM is an initiative of:
