RE: Carousel pattern revisions based on today's meeting

Bryan,

 

Image labels are getting read by the live region. It seems to work pretty
well.

 

We do have some examples with the type of live region you describe. For
instance, the pill list, second example on the layout grid page, has such a
live region. However, we don't yet have guidance for them. That guidance is
coming in the June 2019 release.

 

The example index we are adding to the January release would help you find
examples like that. We have an index by state and property, and that example
is listed for aria-live.

 

Matt

 

From: Bryan Garaventa <bryan.garaventa@levelaccess.com> 
Sent: Tuesday, December 18, 2018 10:44 AM
To: Matt King <a11ythinker@gmail.com>; public-aria-practices@w3.org
Subject: RE: Carousel pattern revisions based on today's meeting

 

In reading the new pattern text, there is a problem with the aria-live
guidance for the slide. It makes sense that this should be set to off on
auto-rotation, and that polite would be used on manual activation only,
however the use of aria-live=polite on a slide doesn't take into account
that only textual content can be recognized in these cases. E.G an image
with an alt would be totally silent, as with any other type of alternative
labelling mechanism for interactive elements like form fields and the like.

 

In such cases, the only way to achieve this is to use an alternate, and
possibly even hidden live region for the purpose of writing custom
information to it, which I don't believe is addressed anywhere in the APG.

 

E.G. This last is a technique that many developers use by appending an
offscreen tag for the purpose of writing custom screen reader messages to be
announced, when there is no means for intuitively doing this within the
standard UI where it would make contextual sense for non-sighted users when
announced as visually displayed.

 

Bryan Garaventa

Principle 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> 

 

From: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> > 
Sent: Monday, December 17, 2018 8:42 PM
To: public-aria-practices@w3.org <mailto:public-aria-practices@w3.org> 
Subject: Carousel pattern revisions based on today's meeting

 

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.

 

Hey all,

 

Thank you for the awesome carousel discussion today. I just pushed the
following changes to the feature branch:

 

*	Revised language throughout the pattern so that auto rotation is not
assumed.
*	Removed use of term "horizontally scroll".
*	Simplified wording of first paragraph.
*	In second paragraph about importance of rotation control: 

*	Added sentence about properly hiding content.
*	Clarified description of auto rotate consequences.

*	Changed rotation control requirements list: 

*	to unordered list.
*	to list essential elements first.
*	To put auto-rotation related requirements in conditional sublist.

*	In Terms, added slide to the definition list.
*	In keyboard requirements, added note saying to not move focus when
activating the prev/next/auto-rotate controls.
*	In states and properties, added optional aria-live guidance to basic
carousel section.

 

One question: In a grouped carousel, Should aria-disabled or aria-current be
used for the picker button that corresponds to the displayed slide. What I
have in the draft now is:

 

"The picker button representing the currently displayed slide has the
property aria-disabled set to true. Note: aria-disabled is preferable to the
HTML disabled attribute because this is a circumstance where screen reader
users benefit from the disabled button being included in the page Tab
sequence."

 

I was leaning toward aria-disabled because I am assuming that activating the
button probably does nothing. It's not like you can "reload" a slide. On the
other hand, this use case precisely fits the definition of aria-current.
Using both current and disabled at the same time would be quite verbose and
kind of overkill.

 

You can read the draft pattern at:

https://raw.githack.com/w3c/aria-practices/issue43-add-carousel-pattern/aria
-practices.html#carousel

 

Best,

Matt