Regarding separator as a widget

Hey all.

Apologies again for having missed the discussion and CfC related to
separator as a widget. Sometimes those all-hands meetings are
inconveniently timed.

I have merged the changes into master as per the group decision. Having
done so, I would like to propose one change that I feel strongly about
and then try one last time to make a case for why aria-expanded on
separator is bad. ;)

The changes made to the spec are meant to make it possible for separator
to be used as a widget without the need for a new role, etc. I'm totally
in favor of that because ATs don't need a dedicated role for this.
HOWEVER, ATs do need certain other things if you want them to do your
bidding. And the text, as written, fails to reliably provide for that.

Let's say we have a vertical focusable separator. The user presses Tab
causing it to gain focus. ATs get a focus event, see that it's a
separator, conclude it's a widget and speak it. What should the AT say?
Personally, something like "splitter, 30%" or if it's named "Foo" then
"Foo, splitter, 30%." The user then presses Right Arrow to nudge the
widget to the right. What should the AT say? Personally I think the new
value, for instance, "40%." If you agree with my suggested behavior,
then I hope you'll also agree that the only way an AT can do your
bidding is if the author provides the current value AND updates the
current value each and every time it changes. At least in the case of my
platform, changing the value results in value change events which
results in Orca announcing the new value. In other words, value is a
must-have. With this in mind, here's what the spec now states:

<quote>
If a separator widget supports continuously variable positioning within
a range of positions, authors MAY use aria-valuenow to specify a
proportional size for one of the sections.
</quote>

That at the very least needs to become a MUST if you don't want crickets
from the AT when the separator widget is moved by the user. Whether or
not a new phrase or sentence telling authors that they MUST update the
value of aria-valuenow each time it changes, I dunno. In my
screen-reader-developer mind, it's obvious. But I don't know how to
think like an author.

(End of issue 1. On to why aria-expanded on separators is bad.)

Those of you at our last call may recall my shock and horror that
aria-expanded was supported on separators which function as widgets.
That it's been supported on separator since at least ARIA 1.0 is not my
fault.<grins>

During the meeting I tried to make the case that the you're not
expanding or collapsing the separator; instead, you're changing its
value. None of you seemed convinced. I wish I had fully read Matt's new
text during the call because I think the new text alludes to the very
thing I'm stating. In particular, the ARIA spec now states:

<quote>
Authors MAY make a separator focusable to create a widget that both
provides a visible boundary between two sections of content and enables
the user to change the relative size of the sections by changing the
position of the separator. [...] Typically, a fixed separator widget is
used to toggle one of the sections between expanded and collapsed states.
</quote>

In the language of the spec, what is being "expanded" or "collapsed" is
one of the sections; not the separator itself.

Let's imagine a web app that lets you view/compare two documents side by
side. Document 1 is on the left, a fixed vertical separator is in the
middle, and Document 2 is on the right. The default position of the
separator is 50%. If you set the position to 0%, Document 1 is hidden
from view (its section is toggled to collapsed, to use the language of
the spec) leaving only Document 2 visible. If you then set the position
to 100%, Document 2 is hidden from view ("collapsed") and at the very
same time Document 1, which had been "collapsed," is now showing (or if
you prefer, "expanded").

I don't think we can assume that a fixed separator will be limited to a
binary expanded/collapsed state. Furthermore, it might be beneficial if
the screen reader didn't just say "expanded" or "collapsed" but gave
some indication of which section was expanded or collapsed (i.e.
Document 1 and/or Document 2). To accomplish that, we would presumably
want to put document 1 and document 2 in containers with a role that
supports aria-expanded. (And I would argue, do not put the state on the
separator, and do expose the current value as it changes between 0, 50,
and 100).

I understand that aria-expanded is a supported state for separator in
ARIA 1.0. I don't think that obligates us to keep it a supported state
in ARIA 1.1. As long as we're adding new supported states and a bunch of
clarifying language, could we not deprecate separator's support for
aria-expanded? Doing so strikes me as being fully consistent with the
new, clarifying text that the sections (and not the separator) whose
expanded state is being toggled. And doing so might simplify the
situation for authors: aria-valuenow would always be required for
separator widgets; not just those "fixed" ones.

(Related aside, if the section on the left is expanded, the separator's
position necessarily moves to the right. And things which move don't
seem "fixed.")

FWIW.
--joanie

Received on Friday, 24 June 2016 19:50:53 UTC