E-mail List Archives
Thread: Need for Increment Buttons?
Number of posts in this thread: 12 (In chronological order)
From: Brandon Keith Biggs
Date: Fri, Dec 14 2018 4:45AM
Subject: Need for Increment Buttons?
No previous message | Next message →
Hello,
Can someone please justify the need for incremental buttons on sliders and
number input elements?
Here is an example of a slider with incremental buttons:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Sliders/Vertical/demo.htm
I'm questioning because Carbon components have two increment buttons for a
number input field that are not very accessible and I would like to know if
they should hide them or keep them visible:
https://deploy-preview-1657--carbon-components-react.netlify.com/?selectedKind=NumberInput&selectedStory=Default&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Fstories%2Fstories-panel
I'm 90% sure on the number field that the buttons should be hidden because
the number input element already says "spin editable" which means that you
can hit enter and adjust the numbers with your keyboard. The buttons, in my
opinion, are 2 redundant UI elements that just introduce complexity and
extra elements on the page.
What do you think?
Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
From: Graham Armfield
Date: Fri, Dec 14 2018 5:17AM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
Hi Brandon,
I've tried the example at:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Sliders/Vertical/demo.htm on
my Android phone with Talkback running, and on my iPad with Voiceover
running. I can't influence the slider directly - only via the
increment/decrement buttons.
Whilst focus is on the slider in Talkback, there is an announcement that I
can use the volume keys to influence the slider but this does not work for
me.
Whilst focus is on the slider in Voiceover, there is an announcement that I
should swipe up or down with one finger to change the value, but that
doesn't work either.
So I guess they're there as a failsafe for mobile screen reader users.
Regards
Graham Armfield
coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>
From: Brandon Keith Biggs
Date: Fri, Dec 14 2018 7:15AM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
Hello,
Wow, you're right, why doesn't either the slider or input number box adjust
the value with swipe up and down, it should.
So the fix for this would be to label the buttons correctly and have an
aria live region on the input field saying the new value.
Thanks,
Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
On Fri, Dec 14, 2018 at 4:18 AM Graham Armfield <
= EMAIL ADDRESS REMOVED = > wrote:
> Hi Brandon,
>
> I've tried the example at:
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Sliders/Vertical/demo.htm on
> my Android phone with Talkback running, and on my iPad with Voiceover
> running. I can't influence the slider directly - only via the
> increment/decrement buttons.
>
> Whilst focus is on the slider in Talkback, there is an announcement that I
> can use the volume keys to influence the slider but this does not work for
> me.
>
> Whilst focus is on the slider in Voiceover, there is an announcement that I
> should swipe up or down with one finger to change the value, but that
> doesn't work either.
>
> So I guess they're there as a failsafe for mobile screen reader users.
>
> Regards
> Graham Armfield
>
> coolfields.co.uk <http://www.coolfields.co.uk/>;
> M:07905 590026
> T: 01483 856613
> @coolfields <https://twitter.com/coolfields>
> > > > >
From: Patrick H. Lauke
Date: Fri, Dec 14 2018 7:48AM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
On 14/12/2018 14:15, Brandon Keith Biggs wrote:
> Wow, you're right, why doesn't either the slider or input number box adjust
> the value with swipe up and down, it should.
The role="slider" exposes it as if it were a real slider (i.e. an <input
type="range">) - which triggers VoiceOver/Talkback to give their usual
hints (use swipe/use volume keys). However, as it's not a real actual
slider, performing those actions by themselves has no effect. From
JavaScript, you can't detect volume key presses on Android. And while
you can detect touchscreen events (and therefore swipes), when AT is
running those gestures are consumed directly by the AT and not passed to
the page/JavaScript (unless you use a passthrough gesture like
double-tap-and-hold).
This sort of thing was mentioned/documented a while ago in
https://www.w3.org/TR/using-aria/#aria-touch
This is one of the scenarios that is hoped will be improved once we have
the Accessibility Object Model (AOM) https://wicg.github.io/aom/spec/
and in particular the related input event types
https://wicg.github.io/aom/spec/input-events.html
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: Jonathan Cohn
Date: Fri, Dec 14 2018 8:46AM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
I guess this might also be why volume sliders in some native IOS applications don't really work. I remember encountering one specific app where VoiceOver indicated that I had adjusted the value of the slider, but then there was no effect on the resulting audio.
I guess a slider is not just a hidden numeric input field with aria used to set min, max, and adjust by values? Because then the SR could just change the value of the input field.
Best Wishes,
Jonathan Cohn
> On Dec 14, 2018, at 9:48 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 14/12/2018 14:15, Brandon Keith Biggs wrote:
>
>> Wow, you're right, why doesn't either the slider or input number box adjust
>> the value with swipe up and down, it should.
>
> The role="slider" exposes it as if it were a real slider (i.e. an <input type="range">) - which triggers VoiceOver/Talkback to give their usual hints (use swipe/use volume keys). However, as it's not a real actual slider, performing those actions by themselves has no effect. From JavaScript, you can't detect volume key presses on Android. And while you can detect touchscreen events (and therefore swipes), when AT is running those gestures are consumed directly by the AT and not passed to the page/JavaScript (unless you use a passthrough gesture like double-tap-and-hold).
>
> This sort of thing was mentioned/documented a while ago in https://www.w3.org/TR/using-aria/#aria-touch
>
> This is one of the scenarios that is hoped will be improved once we have the Accessibility Object Model (AOM) https://wicg.github.io/aom/spec/ and in particular the related input event types https://wicg.github.io/aom/spec/input-events.html
>
> 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, Dec 14 2018 3:28PM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
With VoiceOver, even though it tells you you can swipe up or down to adjust
the value, you have to change your rotor first. There's and "adjust value"
rotor setting and once that's set, then swiping up/down will change the
value.
However, that doesn't work on the whatsock example but it does work on a
native <input type="range">
Glen
From: Patrick H. Lauke
Date: Fri, Dec 14 2018 6:30PM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
On 14/12/2018 22:28, glen walker wrote:
> With VoiceOver, even though it tells you you can swipe up or down to adjust
> the value, you have to change your rotor first. There's and "adjust value"
> rotor setting and once that's set, then swiping up/down will change the
> value.
By default (at least in my experience/my testing), VO/iOS automatically
switches to "adjust value" when you focus on an <input type="range">, so
there's no need to manually change the anything in the rotor first.
> However, that doesn't work on the whatsock example
Because, as said, it's not an actual <input type="range">, but really
just a series of <div> elements with added mouse/touch events/keyboard
events and appropriate aria roles/attributes. The role is what makes VO
believe it's an actual range type input - hence its announcement that
you can swipe up or down to change the value - but as it then doesn't
trigger any of the mouse/touch/keyboard handlers, it doesn't do anything.
> but it does work on a
> native <input type="range">
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, Dec 14 2018 6:57PM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
On Fri, Dec 14, 2018 at 6:30 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> On 14/12/2018 22:28, glen walker wrote:
> > With VoiceOver, even though it tells you you can swipe up or down to
> adjust
> > the value, you have to change your rotor first. There's and "adjust
> value"
> > rotor setting and once that's set, then swiping up/down will change the
> > value.
>
> By default (at least in my experience/my testing), VO/iOS automatically
> switches to "adjust value" when you focus on an <input type="range">, so
> there's no need to manually change the anything in the rotor first.
>
That's what I tested on, iOS. The rotor is not on "adjust value". I have
to change it before swiping up/down. The difference might be if you've
changed the rotor before. That is, I usually have my rotor set to
"vertical navigation" so when I navigate to a range slider, my rotor is
still "vertical navigation". It would be annoying if it suddenly changed
to "adjust value" and then as I'm swiping down vertically, all of a sudden
I start changing the value of a slider rather than continuing to navigate
down.
I think it's a bug in iOS that it says I can swipe up/down to adjust the
value without iOS verifying what my rotor is set to. If the rotor isn't
changed automatically, then it should tell me to set my rotor to "adjust
value" and then I can swipe up/down.
Glen
From: Brandon Keith Biggs
Date: Sat, Dec 15 2018 4:12AM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
Hello,
There is no adjust increment on an <input type="number"> either.
Does VO even recognize spinners?
Thanks,
Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
On Fri, Dec 14, 2018 at 2:28 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> With VoiceOver, even though it tells you you can swipe up or down to adjust
> the value, you have to change your rotor first. There's and "adjust value"
> rotor setting and once that's set, then swiping up/down will change the
> value.
>
> However, that doesn't work on the whatsock example but it does work on a
> native <input type="range">
>
> Glen
> > > > >
From: Bryan Garaventa
Date: Mon, Dec 17 2018 12:24PM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
Hi,
Unfortunately this is a known issue on the iOS platform and does not just impact browser-viewable sliders like the one on WhatSock, but also on any drag and drop type slider that uses standard JavaScript within hybrid applications such as native apps that include web components that do the same thing.
The reason being that, when role=slider is applied to an element, it only changes the native mapping in the accessibility tree in that browser, but does not automatically tie into the native functionality when the same control is implemented using Xcode, which is necessary for the single finger swipe action to automatically scroll the slider as it does in native apps.
The last I heard, Apple has no plan to address this going forward, so it is always necessary to include accessible decrement and increment buttons to address these shortcomings in touch devices for the foreseeable future.
All the best,
Bryan
Bryan Garaventa
Principle Accessibility Architect
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com
From: Bryan Garaventa
Date: Mon, Dec 17 2018 12:27PM
Subject: Re: Need for Increment Buttons?
← Previous message | Next message →
Hi,
From what I can recall, the same issue occurs on role=spinbutton when applied to elements on the web that use standard JavaScript to adjust up or down. Accessible buttons are necessary there too for ensuring touch device support with screen readers.
All the best,
Bryan
Bryan Garaventa
Principle Accessibility Architect
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com
From: Patrick H. Lauke
Date: Mon, Dec 17 2018 12:48PM
Subject: Re: Need for Increment Buttons?
← Previous message | No next message
On 17/12/2018 19:24, Bryan Garaventa wrote:
> Hi,
> Unfortunately this is a known issue on the iOS platform and does not just impact browser-viewable sliders like the one on WhatSock, but also on any drag and drop type slider that uses standard JavaScript within hybrid applications such as native apps that include web components that do the same thing.
Not just iOS. Same thing happens in Android, where anything with a
role="slider" will get Talkback to announce a hint to "use the volume
keys to change the value" (or something to that effect).
> The reason being that, when role=slider is applied to an element, it only changes the native mapping in the accessibility tree in that browser, but does not automatically tie into the native functionality when the same control is implemented using Xcode, which is necessary for the single finger swipe action to automatically scroll the slider as it does in native apps.
>
> The last I heard, Apple has no plan to address this going forward, so it is always necessary to include accessible decrement and increment buttons to address these shortcomings in touch devices for the foreseeable future.
As said, the hope is that AOM events will provide a more sustainable
solution of this problem in future.
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