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
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Matt King <a11ythinker@gmail.com>
Sent: Monday, December 17, 2018 8:42 PM
To: 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