RE: Proposed change to Name and Description change events

Thanks, this issue has been filed at
https://github.com/w3c/core-aam/issues/96

which includes a live example to illustrate the issue.

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: James Scholes <james@pac.bz> 
Sent: Tuesday, November 9, 2021 11:09 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Cc: public-aria-practices@w3.org
Subject: Re: Proposed change to Name and Description change events

WARNING: The sender of this email could not be validated and may not match the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Definitely in favour of this.  The unpredictable nature of when screen readers do and do not convey this information constantly causes implementation complexity for our clients, e.g. in creating a widget where some information is initially conveyed via a description but future updates are then provided via a live region.  The description often has to be dynamically added and removed based on focus just to avoid duplicate speech.

Regards,

James Scholes
Director of Digital Accessibility, Prime Access Consulting, Inc.

On 09/11/2021 at 12:26 pm, Bryan Garaventa wrote:
> Hi,
>
> Currently the name and description change events as documented in the Core AAM work well as they are, where a focused element will fire such an event when one of these properties change dynamically on that element.
>
>
>
> There are scenarios though, which came up today from one of our clients, where this functionality would be good to optionally suppress in some cases. E.G. A textarea field that has an associated character number tooltip that dynamically changes as the user types into that field. In this case, the character count is announced over all characters typed in, and the field itself is meant to provide a means for drafting an essay so there are thousands of characters that can be typed into the field.
>
>
>
> In general, the name and description change events should continue to work as they are. However, in cases where it is more accessible to optionally suppress these events, would it be reasonable to allow the explicit setting of aria-live=”off” to negate this functionality in limited circumstances? It doesn’t seem possible to leave this up to ATs to do this on their end, mainly because this will lead to some things working one way on some operating systems and differently on others.
>
>
>
> If agreeable, where should this be filed against, the Core AAM or AccName specs?
>
>
>
> Thanks,
>
> Bryan
>
>
>
>
>
>
>
>
>
> Bryan Garaventa
>
> Principal Accessibility Architect
>
> Level Access, Inc.
>
> Bryan.Garaventa@LevelAccess.com <mailto:Bryan.Garaventa@LevelAccess.com>
>
> 415.624.2709 (o)
>
> www.LevelAccess.com <http://www.levelaccess.com/>
>
>
>

Received on Wednesday, 10 November 2021 19:38:30 UTC