Re: Regarding separator as a widget

So, expanded can be fired by the browser per platform for focusable widgets without the author having to apply it. Then it makes sense to not have the author provide the property. So, we would have to deprecate it.

Second, check with Cynthia to make sure this will not violate a UIA control pattern regarding values. 

Rich

> On Jun 24, 2016, at 2:50 PM, Joanmarie Diggs <jdiggs@igalia.com> wrote:
> 
> 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 21:17:23 UTC