W3C home > Mailing lists > Public > public-aria@w3.org > May 2016

Re: aria-ISSUE-1028 (SeparatorNotWidget): Separator is a structure but the description says it can be interactive [ARIA 1.1]

From: Joanmarie Diggs <jdiggs@igalia.com>
Date: Wed, 18 May 2016 18:10:16 -0400
Cc: public-aria@w3.org
To: Matt King <a11ythinker@gmail.com>
Message-ID: <7113c770-744b-e4a6-7ba7-3ce26bb9c42f@igalia.com>
Hey Matt, all.

I'm not opposed to the addition of a "separator" role and the problem
you outline here does indeed sound like a problem. That said, to play
devil's advocate, do we need a new role to solve this?

If authors MUST make interactive separators keyboard focusable via
setting the tabindex, and the Core AAM maps focusable separators to each
platform's splitter role, then it should be operable with screen
readers. Furthermore, existing web apps which use role separator
combined with a tabindex could become screen-reader-operable without the
author having to change anything.


On 05/18/2016 04:45 PM, Accessible Rich Internet Applications Working
Group Issue Tracker wrote:
> aria-ISSUE-1028 (SeparatorNotWidget): Separator is a structure but the description says it can be interactive [ARIA 1.1]
> http://www.w3.org/WAI/ARIA/track/issues/1028
> Raised by: Matthew King
> On product: ARIA 1.1
> The separator role is a structure. Screen readers render elements with role separator in the same way that the HTML HR element is rendered. Thus, screen readers regard separators as static, not interactive. 
> Yet, the description of the separator role says that a separator may be a movable splitter that divides parts of a window. So, the APG Window splitter pattern states that the separator role should be used for an interactive window splitter.
> Obviously, If you make a focusable, interactive window splitter and give it the separator role, it will not be operable with screen readers because they will not recognize a separator as interactive and neding to consume keys like arrows, home, and end.
> The superclass of separator can not be change to be a widget without breaking its ability to serve as an equivalent to HR. the widget role can not be added as a second superclass because there would not be a way for assistive technologies to discern if the element is a separator or a splitter.
> Proposal:
> 1. Remove language about interaction from the separator role.
> 2. Add a splitter role that is a widget.
Received on Wednesday, 18 May 2016 22:10:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:26 UTC