RE: Hiding low priority visual updates

Hi Greg,

One thing to consider is that even if aria-live could apply to visual rendering, the common perception is that it doesn't, so only the changing text itself gets the markup (e.g. http://test.cita.illinois.edu/aria/live/live1.php)

Hiding just the dynamic text, but not any related static text or dynamic images, seems like it could just make the UI more confusing.

Cheers,
Jan


(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
OCAD UNIVERSITY

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca<mailto:jrichards@ocadu.ca?Subject=Re%3A%20AUWG%20Teleconference%20for%2017%20March%202014%20%28Boston%20time%20has%20changed%20-%20%20please%20re-check%20time%29&In-Reply-To=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E&References=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E>

________________________________
From: Greg Lowney [gcl-0039@access-research.org]
Sent: July-17-14 11:10 PM
To: Rich Schwerdtfeger
Cc: WAI-UA list
Subject: Hiding low priority visual updates

Hi Rich,

The User Agent Working Group is trying to do more to address the needs of users with cognitive disabilities, and to this end *we’re considering recommending that user agents let the user choose to disable visual updates that are marked as low priority*. This would primarily be for users who find it difficult to deal with constant distractions caused by updating visual information, and would prefer to hide unnecessary updates.

The primary way to mark regions as low priority is with the aria-live politeness value of "off". The question is, would this be misusing and abusing the aria-live attribute, or is this a legitimate way to make use of the author’s markup? The description of aria-live in the ARIA spec (http://www.w3.org/TR/wai-aria/complete#aria-live) talks explicitly about assistive technology, but is ambiguous on whether or how user agents should handle it for users who do NOT rely on assistive technology.

Some arguments in favor of this interpretation include:
*    The first paragraph says "Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region." This says it’s about what "users" can expect, not just users of assistive technology. The second paragraph, likewise, does not restrict itself to users of assistive technology.
*    The third paragraph explicitly says "Politeness levels are essentially an ordering mechanism for updates and serve as a strong suggestion to *user agents* or assistive technologies" (emphasis added). Again, this strongly suggests user agents should change some behavior based on the attribute.
*    The definition of aria-live:none is just the flat-out statement "Updates to the region will not be presented to the user", without saying that it applies only to assistive technology. (On the other hand, the entries for the "polite" and "assertive" values contain explicit guidance for assistive technology, but don’t say anything about user agents. That could mean that it's not relevant to user agents, but it could merely mean that user agents aren't supposed to do anything special with regions with those values, just letting them update normally.)

Some arguments against this interpretation include:
*    The fourth paragraph says "it is up to the user to tweak his or her assistive technologies' response to a live region with a certain politeness level from the commonly defined baseline", with no mention of being able to tweak behaviors by the user agent.
*    Descriptions of the "polite" and "assertive" values do not address anything other than AT.
*    "Off" is the default value, which would be okay if "aria-live" with no value is interpreted as "off", and thus not visually updated, but would certainly not work if it implied that everything lacking the aria-live attribute was to be treated as if it had the attribute with the value of "off". However, the latter interpretation would mean that screen readers weren’t supposed to announce *any* changes except where the region is designated polite or assertive (either by aria-live or a role that implies it), and that doesn’t seem right, either.
*    WAI-ARIA Authoring Practices 1.0 (non-normative?) discusses how AT should handle aria-live, but does not say anything about how user agents should handle it. (On the other hand, it does not explicitly say that they should not, and the general purpose statement "Live regions are parts of a Web page that the author expects to change" certainly could imply it could be used more generally.) It also describes the "off" value with "Any updates made to this region must not be announced to the user." Use of the term "announce" makes it sound more AT-specific than the description in the spec itself, although I don’t know that the term is defined anywhere as audio-only.

We’d appreciate your thoughts on this.

As an aside, it might also be possible for a user style sheet to hide all elements with aria-live:none, or for a user script to toggle their display. There are browser extensions that let users hide individual elements that are causing them trouble, but that’s not a practical solution if, for example, the user has to repeat it every time they navigation to a new page on the site.

>From a UI perspective, it’s arguable whether hiding the live region or freezing it would be more problematic: the former prevents the user from knowing what they’re missing, while the latter risks them acting on outdated information. The former could be easily fixed by replacing the live region with a placeholder, but it would be harder to denote a region as frozen without changing its size or obscuring its content.

    Thanks,
    Greg