E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 17 (In chronological order)

From: Isabel Holdsworth
Date: Wed, Feb 27 2019 8:14AM
Subject: Sliders and MouseDown
No previous message | Next message →

Hi all,

Any thoughts on whether WCAG 2.1 guideline 2.5.2 might apply to sliders?

For normal drag-and-drop components, if a user starts dragging an
element then changes their mind, dragging it somewhere outside the
permitted drop zones causes the element to be plonked back where it
started.

Should the same behaviour apply when a user begins dragging a slider
thumb, say, on the volume control or play-head of a media player? If
they begin dragging the play-head then have a change of heart and move
the pointer outside the slider, should the play-head jump back to
where it started? And if it doesn't, would this fail 2.5.2?

Lots of stuff to grapple with in my first 2.1 audit :-)

Thanks as always for your thoughts.

Cheers, Isabel

From: Steve Green
Date: Wed, Feb 27 2019 9:25AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

That's a really good point. My (possibly incorrect) understanding is that your analysis is correct, and that there should be a way to cancel and return to the original slider position. However, I have not been able to find any example of a slider that has such a behaviour.

I would not have thought that it would be too difficult to use the Escape key to do this, but I am not a developer so nothing looks difficult from my perspective.

Steve Green
Managing Director
Test Partners Ltd

From: Isabel Holdsworth
Date: Thu, Feb 28 2019 3:17AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

Hi Steve,

Pressing ESC may not be an option for some pointer users, and I don't
think would be accepted as a sufficient technique for 2.5.2, which
seems to stipulate that it must be possible to cancel a DOWN event
using only the pointer.

I wish I knew whether or not this behaviour applies to sliders.

Cheers, Isabel

On 27/02/2019, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> That's a really good point. My (possibly incorrect) understanding is that
> your analysis is correct, and that there should be a way to cancel and
> return to the original slider position. However, I have not been able to
> find any example of a slider that has such a behaviour.
>
> I would not have thought that it would be too difficult to use the Escape
> key to do this, but I am not a developer so nothing looks difficult from my
> perspective.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
>

From: Steve Green
Date: Thu, Feb 28 2019 4:12AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

I can't see anything that says that cancellation must be possible using only the pointer, although I agree that would be ideal. The Understanding page says that moving the pointer away from the target before releasing is one way to achieve cancellation, but it does not say it is the only way.

It also says that cancellation can be achieved by returning the selected item to its original location. While that may be possible for sliders that have a relatively small number of values, it is not a realistic option for sliders that are infinitely variable, such as the timeline on a video.

This is another example of a WCAG 2.1 success criterion that would benefit from additional explanation and examples, so I hope the authors will address this.

Steve

From: Isabel Holdsworth
Date: Thu, Feb 28 2019 4:27AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

Thanks Steve. I read somewhere on the W3C website that cancelling a
pointer gesture shouldn't require a keyboard as some people using
alternative input devices might not be able to use one. I should have
kept a note of where :-(

On 28/02/2019, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> I can't see anything that says that cancellation must be possible using only
> the pointer, although I agree that would be ideal. The Understanding page
> says that moving the pointer away from the target before releasing is one
> way to achieve cancellation, but it does not say it is the only way.
>
> It also says that cancellation can be achieved by returning the selected
> item to its original location. While that may be possible for sliders that
> have a relatively small number of values, it is not a realistic option for
> sliders that are infinitely variable, such as the timeline on a video.
>
> This is another example of a WCAG 2.1 success criterion that would benefit
> from additional explanation and examples, so I hope the authors will address
> this.
>
> Steve
>
>
>
>

From: Mohith BP
Date: Thu, Feb 28 2019 10:41PM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

Hi Isabel,

This is bit tricky. Please find my thoughts below.
I feel this SC is applicable for sliders.
Understanding 2.5.2 states:
"The most accessible way to incorporate pointer cancellation is to
make activation occur on the up-event."

Going by the above sentence and if you are going to confirm by this
methodology, it is sure that once the users mouse down and drag till
the desired place and only by releasing the mouse pointer should
activate the event.

It means if the slider is a volume then even the users drag the slider
they will not get the volume up or down till they release the pointer.
This may cause some usability issues for the users expecting dragging
along increases the volume and they can leave at the place where they
feel comfortable.

I feel it is good to provide the Up event only activation is right as
per this SC and it is required to bring the slider where it was if the
pointer is released out of the slider area.

This SC states many ways such as providing an UnDo button, etc.
You can explore other options such as showing an UnDo when drag and
drop on Sliders happens.


Thanks & Regards,
Mohith B. P.

On 2/27/19, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all,
>
> Any thoughts on whether WCAG 2.1 guideline 2.5.2 might apply to sliders?
>
> For normal drag-and-drop components, if a user starts dragging an
> element then changes their mind, dragging it somewhere outside the
> permitted drop zones causes the element to be plonked back where it
> started.
>
> Should the same behaviour apply when a user begins dragging a slider
> thumb, say, on the volume control or play-head of a media player? If
> they begin dragging the play-head then have a change of heart and move
> the pointer outside the slider, should the play-head jump back to
> where it started? And if it doesn't, would this fail 2.5.2?
>
> Lots of stuff to grapple with in my first 2.1 audit :-)
>
> Thanks as always for your thoughts.
>
> Cheers, Isabel
> > > > >

From: Patrick H. Lauke
Date: Fri, Mar 01 2019 1:22AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

On 01/03/2019 05:41, Mohith BP wrote:
[...]
> This SC states many ways such as providing an UnDo button, etc.
> You can explore other options such as showing an UnDo when drag and
> drop on Sliders happens.

At a very high level, I'd say there's an argument that for things like a
volume slider there's an undo option in that a user can go back and
change the volume again. It's not an action that's irreversible.
However, that *may* be stretching the definition a tad.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Isabel Holdsworth
Date: Fri, Mar 01 2019 2:37AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

Thanks guys for your thoughts.

This is very frustrating. I'm not sure whether to pass or fail the
sliders in my audit. I know this type of issue will be fleshed out
once there's an increased uptake of 2.1, but in the meantime I might
pass these sliders and the next auditor might fail them, and there's
no right answer.

Organisations understandably express frustration when they get two
different results from two auditors. WCAG feels like a black art
sometimes. The fact that it exists is a huge positive, but
interpreting it can be so difficult on occasion.

On 01/03/2019, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 01/03/2019 05:41, Mohith BP wrote:
> [...]
>> This SC states many ways such as providing an UnDo button, etc.
>> You can explore other options such as showing an UnDo when drag and
>> drop on Sliders happens.
>
> At a very high level, I'd say there's an argument that for things like a
> volume slider there's an undo option in that a user can go back and
> change the volume again. It's not an action that's irreversible.
> However, that *may* be stretching the definition a tad.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: glen walker
Date: Fri, Mar 01 2019 3:15AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

I don't like the slider *not* updating as it's being dragged. Whether for
volume, or a seek bar, or for a color change. For the latter, see WebAIM's
contrast checker, https://webaim.org/resources/contrastchecker/#maincontent.
If you're a mouse user, you can drag the slider for the color and see the
color box change and the pass/fail options update. As a keyboard user, I
can use left/right arrows to see the changes. If you press and hold an
arrow key, it's kind of like dragging the slider, except you can't
escape/undo it. On firefox, I can hit escape while dragging with the mouse
and it'll cancel the change. Neither chrome nor IE support that.

Keep in mind that 2.5.2 has a list of "at least one of the following is
true". The canceling of the mouse drag is just one of them. If you don't
support canceling, then perhaps you can satisfy one of the others. In the
case of a volume or seek or color bar, I would argue that the fourth bullet
point applies - "Essential: Completing the function on the down-event is
essential". Allowing the user to hear the volume change as you're dragging
could be considered "essential". Seeing a color box change and pass/fail
options update could be considered "essential". It might be a subjective
argument, but that's nothing new.

Glen

From: Isabel Holdsworth
Date: Fri, Mar 01 2019 3:30AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

Very good points Glen - thank you. I think I could easily pass these
under the "essential" criterion. I predict a happy customer moment :-)

Thanks all.

On 01/03/2019, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I don't like the slider *not* updating as it's being dragged. Whether for
> volume, or a seek bar, or for a color change. For the latter, see WebAIM's
> contrast checker,
> https://webaim.org/resources/contrastchecker/#maincontent.
> If you're a mouse user, you can drag the slider for the color and see the
> color box change and the pass/fail options update. As a keyboard user, I
> can use left/right arrows to see the changes. If you press and hold an
> arrow key, it's kind of like dragging the slider, except you can't
> escape/undo it. On firefox, I can hit escape while dragging with the mouse
> and it'll cancel the change. Neither chrome nor IE support that.
>
> Keep in mind that 2.5.2 has a list of "at least one of the following is
> true". The canceling of the mouse drag is just one of them. If you don't
> support canceling, then perhaps you can satisfy one of the others. In the
> case of a volume or seek or color bar, I would argue that the fourth bullet
> point applies - "Essential: Completing the function on the down-event is
> essential". Allowing the user to hear the volume change as you're dragging
> could be considered "essential". Seeing a color box change and pass/fail
> options update could be considered "essential". It might be a subjective
> argument, but that's nothing new.
>
> Glen
> > > > >

From: Mallory
Date: Fri, Mar 01 2019 3:54AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

Yeah agreed with Mohit that the dragging of our slider should be similar to the dragging of a draggable in drag and drop-- where we must use the down event for the dragging (and here to gauge the effects of the movement such as in a volume control), and the up event is for *setting the new stable position of the slider thumb*.

It's too bad you don't have the option of a Warning type, where the suggestion of having something to reset to the old position hits everything and "solves" the Warning. Having the pointer be somewhere else and letting go to "undo" as is typical of drag and drop may not be the best idea as many applications with tiny tiny slider thumbs are really only usable with clumsy mouse control if you can let up anywhere to set the new-stable position. I rely on this up-event-not-cancelling while using image editors all the time-- I simply cannot be precise enough otherwise.

So something (a button or a keystroke or both) that goes back to last-stable position sounds to me like the most useful solution.

cheers,
_mallory

From: Detlev Fischer
Date: Fri, Mar 01 2019 4:02AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

While the mouse is down and the slider is moved, it should certainly
already update the value so in case of a volume control the user has
immediate feedback. There is nothing wrong with immediately updating the
values anyway (not just when this is essential) - the point is that the
release of the mouse button /finger lift-off ouside the active area of
the slider (which should certainly be wider than a couple of pixels)
should revert the thumb to the original position. When this does not
happen, my hunch is that the control would need to claim an essential
exception (which might be OK for volume as it is easily revertable).
Taking the videoexample, the situation is perhaps more tricky - you
definitely need feedback / change of position values while dragging
here. Reverting to the old position when releasing the mouse outside the
track area does not seem to be the common behaviour (just checked
YouTube, Vimeo and a few other players). The exact old position in the
video will be difficult to locate without the thumb reverting. I guess
such a behaviour would have benefits but probably also downsides, so I
would feel inclined to accept an essential exception for video track
sliders.
Detlev

Am 01.03.2019 um 11:30 schrieb Isabel Holdsworth:
> Very good points Glen - thank you. I think I could easily pass these
> under the "essential" criterion. I predict a happy customer moment :-)
>
> Thanks all.
>
> On 01/03/2019, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>> I don't like the slider *not* updating as it's being dragged. Whether for
>> volume, or a seek bar, or for a color change. For the latter, see WebAIM's
>> contrast checker,
>> https://webaim.org/resources/contrastchecker/#maincontent.
>> If you're a mouse user, you can drag the slider for the color and see the
>> color box change and the pass/fail options update. As a keyboard user, I
>> can use left/right arrows to see the changes. If you press and hold an
>> arrow key, it's kind of like dragging the slider, except you can't
>> escape/undo it. On firefox, I can hit escape while dragging with the mouse
>> and it'll cancel the change. Neither chrome nor IE support that.
>>
>> Keep in mind that 2.5.2 has a list of "at least one of the following is
>> true". The canceling of the mouse drag is just one of them. If you don't
>> support canceling, then perhaps you can satisfy one of the others. In the
>> case of a volume or seek or color bar, I would argue that the fourth bullet
>> point applies - "Essential: Completing the function on the down-event is
>> essential". Allowing the user to hear the volume change as you're dragging
>> could be considered "essential". Seeing a color box change and pass/fail
>> options update could be considered "essential". It might be a subjective
>> argument, but that's nothing new.
>>
>> Glen
>> >> >> >> >>
> > > > --
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg

Mobil +49 (0)157 57 57 57 45

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

From: Isabel Holdsworth
Date: Fri, Mar 01 2019 4:48AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

I think there are going to be a lot of essential exception claims for
this one. I might as well start the ball rolling ...

On 01/03/2019, Detlev Fischer < = EMAIL ADDRESS REMOVED = > wrote:
> While the mouse is down and the slider is moved, it should certainly
> already update the value so in case of a volume control the user has
> immediate feedback. There is nothing wrong with immediately updating the
> values anyway (not just when this is essential) - the point is that the
> release of the mouse button /finger lift-off ouside the active area of
> the slider (which should certainly be wider than a couple of pixels)
> should revert the thumb to the original position. When this does not
> happen, my hunch is that the control would need to claim an essential
> exception (which might be OK for volume as it is easily revertable).
> Taking the videoexample, the situation is perhaps more tricky - you
> definitely need feedback / change of position values while dragging
> here. Reverting to the old position when releasing the mouse outside the
> track area does not seem to be the common behaviour (just checked
> YouTube, Vimeo and a few other players). The exact old position in the
> video will be difficult to locate without the thumb reverting. I guess
> such a behaviour would have benefits but probably also downsides, so I
> would feel inclined to accept an essential exception for video track
> sliders.
> Detlev
>
> Am 01.03.2019 um 11:30 schrieb Isabel Holdsworth:
>> Very good points Glen - thank you. I think I could easily pass these
>> under the "essential" criterion. I predict a happy customer moment :-)
>>
>> Thanks all.
>>
>> On 01/03/2019, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>> I don't like the slider *not* updating as it's being dragged. Whether
>>> for
>>> volume, or a seek bar, or for a color change. For the latter, see
>>> WebAIM's
>>> contrast checker,
>>> https://webaim.org/resources/contrastchecker/#maincontent.
>>> If you're a mouse user, you can drag the slider for the color and see the
>>> color box change and the pass/fail options update. As a keyboard user, I
>>> can use left/right arrows to see the changes. If you press and hold an
>>> arrow key, it's kind of like dragging the slider, except you can't
>>> escape/undo it. On firefox, I can hit escape while dragging with the
>>> mouse
>>> and it'll cancel the change. Neither chrome nor IE support that.
>>>
>>> Keep in mind that 2.5.2 has a list of "at least one of the following is
>>> true". The canceling of the mouse drag is just one of them. If you
>>> don't
>>> support canceling, then perhaps you can satisfy one of the others. In
>>> the
>>> case of a volume or seek or color bar, I would argue that the fourth
>>> bullet
>>> point applies - "Essential: Completing the function on the down-event is
>>> essential". Allowing the user to hear the volume change as you're
>>> dragging
>>> could be considered "essential". Seeing a color box change and pass/fail
>>> options update could be considered "essential". It might be a subjective
>>> argument, but that's nothing new.
>>>
>>> Glen
>>> >>> >>> >>> >>>
>> >> >> >> >
> --
> Detlev Fischer
> Testkreis
> Werderstr. 34, 20144 Hamburg
>
> Mobil +49 (0)157 57 57 57 45
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
> > > > >

From: glen walker
Date: Fri, Mar 01 2019 8:08AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

On the rare occasion that I pick up a mouse, I do use the feature (works in
firefox, chrome, and ie) that when dragging the browser's thumb when
reading a long article, if I drag too far horizontally, the thumb pops back
to it's original location (essentially a cancel). I do this when I know
there is something in the article that I want to see while also keeping my
place in the article. I'll drag the thumb to go back, look at what I need
to see while keeping the mouse button down, and then intentionally drag
sideways to cancel the scroll so I'm back to where I was reading. The same
could happen for a volume or seek or color slider, although ideally that
should be built in to the slider widget by the browser.

Glen

From: Birkir R. Gunnarsson
Date: Fri, Mar 01 2019 10:42AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

How does a native slider (an <input type="range"> element work with
the mouse in browser)?
I could thorw together a rough example, but I don't use a mouse and I
don't even know if this input results in a visible slider though I am
95%+ sure it does) so I couldn't test it.


On 3/1/19, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> On the rare occasion that I pick up a mouse, I do use the feature (works in
> firefox, chrome, and ie) that when dragging the browser's thumb when
> reading a long article, if I drag too far horizontally, the thumb pops back
> to it's original location (essentially a cancel). I do this when I know
> there is something in the article that I want to see while also keeping my
> place in the article. I'll drag the thumb to go back, look at what I need
> to see while keeping the mouse button down, and then intentionally drag
> sideways to cancel the scroll so I'm back to where I was reading. The same
> could happen for a volume or seek or color slider, although ideally that
> should be built in to the slider widget by the browser.
>
> Glen
> > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Fri, Mar 01 2019 10:58AM
Subject: Re: Sliders and MouseDown
← Previous message | Next message →

I had tried that the other day using the sample on w3schools -
https://www.w3schools.com/howto/howto_js_rangeslider.asp

On a PC with firefox, I can hit escape to cancel the thumb drag. On chrome
and ie, I cannot cancel the drag.

There doesn't seem to be an area where the drag is canceled if I move
outside that area, so it doesn't work like the browser's page scroll widget
(but would be nice if it did).

On Fri, Mar 1, 2019 at 10:42 AM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> How does a native slider (an <input type="range"> element work with
> the mouse in browser)?
>
>

From: Isabel Holdsworth
Date: Mon, Mar 04 2019 5:04AM
Subject: Re: Sliders and MouseDown
← Previous message | No next message

Thanks Glen.

With a slider that has a small number of steps, such as a 10-step
volume control, it's easy to revert to the exact place where the thumb
was positioned before it was dragged.

However, with an infinite slider such as a play-head, it would be nigh
on impossible to get back to the exact same position. Would the
inability to cancel a drag constitute a fail in instances like this?

Grateful for your thoughts as always.

Cheers, Isabel

On 01/03/2019, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I had tried that the other day using the sample on w3schools -
> https://www.w3schools.com/howto/howto_js_rangeslider.asp
>
> On a PC with firefox, I can hit escape to cancel the thumb drag. On chrome
> and ie, I cannot cancel the drag.
>
> There doesn't seem to be an area where the drag is canceled if I move
> outside that area, so it doesn't work like the browser's page scroll widget
> (but would be nice if it did).
>
> On Fri, Mar 1, 2019 at 10:42 AM Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> How does a native slider (an <input type="range"> element work with
>> the mouse in browser)?
>>
>>
> > > > >