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

Rich, please read the issue so you can understand why separator does not work for an interactive window splitter. TL;DR … Separator is a structure, not a widget.

 

My minimum proposal is to get rid of the language that causes readers to falsely believe you could use separator as a splitter widget. Then, at least we can prevent incorrect use of a structural role.

 

If you think window splitters are not worth the trouble now, even as an at risk feature, then we have two alternatives for the APG:

1.      Remove the defective window splitter pattern from the APG.

2.      Build the window splitter pattern with role application and a roledescription of “window splitter”.

 

In our recent review of the window splitter pattern in the APG TF, Some members said window splitters are important enough that we should not remove the pattern; people build them so they need guidance. I think IBM may even use them in the knowledge center. At the same time, no one is excited about using role application for this purpose … but it could serve as a stopgap until ARIA 2.0.

 

Matt

 

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Wednesday, May 18, 2016 5:43 PM
To: Joanmarie Diggs <jdiggs@igalia.com>
Cc: Matt King <a11ythinker@gmail.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: aria-ISSUE-1028 (SeparatorNotWidget): Separator is a structure but the description says it can be interactive [ARIA 1.1]

 

Having another splitter role is wasteful. We already have a separator that can be used for that purpose and it has been. 

 

This is an unnecessary last minute addition that is a late unfiled issue. We are trying to lock ARIA down. Adding new  role that we have to map does not help that. I am also not convinced that this is a show stopper for authoring practices.

 

Let’s get some discipline so that we can get this thing shut down. 

 

Matt, I have said multiple times that we are trying to lock this down in June. Asking to add yet another role past the middle of May that we have to create mappings for is ridiculous AND no issue was never filed on it.  It also does not fall under identified serious web problems and it does not fill an essential gap in HTML5 mappings. 

 

This should be logged as a new ARIA 2.0 issue and we should decide about this in an ARIA 1.2  … no different than aria-valuestep. We asked James Craig to hold off and you should not be an exception. The group still need to review the entire spec. 

 

I will be back Monday. Janina is chairing tomorrow. 

 

Rich

Rich Schwerdtfeger

 

 

 

On May 18, 2016, at 5:19 PM, Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com> > wrote:

 

In the message below, I mean the addition of a *splitter* role.
Apologies for the noise/spam.

--joanie

On 05/18/2016 06:10 PM, Joanmarie Diggs wrote:



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.

--joanie

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.