Re: Regarding separator as a widget

Joanie, 

aria-expanded was in 1.0. Why are you in shock and awe? :-)

ATs expect this on other platforms. Are you suggesting to add valuemax, valuemin, and currentvalue as well and providing additional text to cover when aria-expanded should be fired? 

I don’t think it is a problem to make these values a MUST - but we need to state what the values would be in the case of a static separator. It would impact some authors but it would not break ATs that were following expanded and collapsed. … IOW the expanded could be the case when it was fully expanded (aria-expanded=“true”, and collaped when aria-expanded=“false”)


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 20:38:45 UTC