Add temperature slider based on HTML range input

[jongund]

This example uses input[type=range] using aria-valuetext and aria-orientation.
The slider focus group meeting suggested a range control example using aria-valuetext would be useful for people to compare with slider widgets.

Preview Link

Review checklist

• Editorial review by @mcking65
• Functional review by @mcking65
• Visual design review by @a11ydoer
• Accessibility review by @shirsha
• iOS device review by @jongund
• Android device review by @jongund
• Code review by @jesdaigle
• Test review by @jesdaigle

[jongund]

@patrickhlauke
Can you checkout this range example using aria-valuetext and aria-orientation when you get a chance.
I would be grateful to you for any feedback you have.

[carmacleod]

@jongund Just a visual nit - the length of the Fan slider (range input) and the Heat/Cool slider (range input) are the same, but the Fan slider should be longer because it has 4 labels, and the Heat/Cool slider only has 3. (Interestingly, they are a bit longer in FF, and a bit shorter in Chrome.)

[patrickhlauke]

for this and the other two: i'll check these over the weekend, if that's ok time-wise

[jongund]

@patrickhlauke
You comments are welcome anytime, and next week works.

[patrickhlauke]

General comment: I'd love to see these examples use

<meta name="viewport" content="width=device-width, initial-scale=1.0">

(though that will then also require some tweaking of the table styles to avoid them pushing out the content/leading to horizontal scrolling of the whole page) to make the experience a bit more mobile/small-screen friendly.

This example works very well on a Surface touchscreen, on iPhone/Safari, reasonably in iPhone/Chrome (seems the webview used for Chrome gets a bit flakey with respecting the touch-action once pinch-zoomed in ... this would become a non-issue once mobile-friendly viewport is added with the above meta). Also works well with iPhone/VoiceOver.

Android/Chrome/TalkBack announces percentage only when focusing a thumb. Users can change value by double-tap-and-hold-ing the thumb, then moving their finger. Changing percentage value is announced when moving.

The fact that it only announces percent values becomes confusing/an issue in the Fan and Heat/Cold examples. Hearing that "Fan" is at "25 percent" is even more meaningless to users in this case. Yes, it's a shortcoming in TalkBack of course, but at least in the case of a numeric slider that represents a range of values, it can "almost" be understandable (though without knowing min/max either, yeah, it's of low information value for these users).

Incidentally, I'm actually wondering if using sliders for these two cases is semantically appropriate. They're not really offering a sliding scale of values that the user jumps between, but conceptually they are mutually exclusive radio buttons?

Lastly, as these examples use an actual <input>, there's no need to add the touch-action. In fact, I'd recommend removing these CSS rules altogether as they may interfere here.

[patrickhlauke]

and yes, the fact that the slider for "Fan" was visually shorter than the labels/buttons underneath it was confusing, visually

[patrickhlauke]

for some reason, Chrome/TalkBack also didn't announce the actual displayed temperature in the <output>. It just announced the element as "Temperature, status" without announcing the value. Seems TB is quite confused/broken, sadly.

[mcking65]

@jongund

Perhaps we can discuss this tomorrow. I'm thinking that our HTML examples should exactly mimic an ARIA example. I'm not sure which slider would be best to mimic. I think it would be ideal if it were one that required the least amount of JS and ARIA.

When deciding which one, it seems to me that Minimizing JS would be more important than the number of ARIA attributes. That would rank implementations that don't use valuetext higher .... unless there is some creative way of using valuetext without a script.

[jongund]

@mcking65
I have made the updates to the example, so should be ready for testing.

Jon

[jongund]

@mcking65
I updated the example to use just the input event to update aria-valuetext and it works on Windows, macOS, iOS and Android without any asssistive technologies and with NVDA on Windows. When VO or TalkBack are enabled you can change the value of the slider using the AT, but aria-valuetext is not updated or read, basically input event is not triggered by the way VO or TalkBack change the slider value. Adding other events like pointermove also do not update arai-avaluetext with VO or TalkBack.

[patrickhlauke]

perhaps listening to change rather than (or in addition to) the input event may help?

[a11ydoer]

@patrickhlauke yes, that is what we talked about at the meeting. Change event is more reliable/stable than input event.

[jongund]

@patrickhlauke
I was using the change, keydown and pointermove events before, but the input event seems to simplify the events without loss of function, even on mobile devices. I don;t think mobile assistive technologies (e.g. VO and TalkBack) change the range value trigger any DOM events for updating the visual or the aria-valuetext value. Let me know if you have any experience with a DOM event that does trigger when an assistive technology changes the value of the range slider.

[patrickhlauke]

@patrickhlauke
I was using the change, keydown and pointermove events before, but the input event seems to simplify the events without loss of function, even on mobile devices. I don;t think mobile assistive technologies (e.g. VO and TalkBack) change the range value trigger any DOM events for updating the visual or the aria-valuetext value. Let me know if you have any experience with a DOM event that does trigger when an assistive technology changes the value of the range slider.

I just brutally grabbed your example, slotted it into codepen, and replaced input with change event. seems to work fine in Safari/VO/iOS. on Android/Chrome/TalkBack, there's some weirdness (for me at least) getting focus on the actual input (it seemed to keep skipping it when just swiping through the page), but when explicitly setting focus to it with touch-to-explore, it let me change the value with volume keys (but, as seems to be the case with TalkBack, it always consistently announced the value of the slider in percent, rather than the aria-valuetext).

on both platforms, using AT, the visible celsius value is changed, so the event is fired properly even when triggered by AT

https://codepen.io/patrickhlauke/pen/4b3f6b49d2bd1889ecc99e1f08b6545e

[patrickhlauke]

typo in class name, and not actually used. just remove the whole class="veritcal" here

[jongund]

Thanks, I will update

[jongund]

@patrickhlauke
I changed the example to use the change and pointermove events and it is working on iOS and Android. Thanks for looking into this.

[shirsha]

As discussed before, Narrator in Scan mode, unable to change the temperature values.

[jscholes]

From the keyboard support section of the example:

Page Up/Down: Increases/decreases temperature slider value multiple steps. In this slider, jumps 18 steps (e.g. 1.8°C) on most browsers.

There are some editorial issues with this text, i.e. it should be "by multiple steps", and if 18 steps represents 1.8 degrees, "e.g." isn't appropriate because that's just a fact of the implementation rather than an example.

However, I don't understand the intention here overall.

• Why does the number of steps differ by browser?
• Why is 1.8 degrees the chosen step amount? The arrow keys move by 0.1, and 1.8 seems completely arbitrary. Why not 1 degree, 2 degrees or some other round number?
• On my computer, in Firefox and Chrome Page Up/Down move by 2.8 degrees not 1.8.

[jongund]

@jscholes
The example is dependent on the built-in keyboard support of the input[type=range] form control, so the browser determines the change in value for the page up and page down keys. We are only adding the aria-valuetext attribute to the input element in this example.

[jscholes]

@jongund That will make this example impossible to test within ARIA-AT, has really poor usability, and IMHO sets a pretty bad precedent for including instructions within APG examples that may only work as described in certain situations. I suggest that Page Up/Down be overridden to either:

1. move by a predictable, consistent step amount; or
2. do nothing, i.e. act as a no-op.

I don't like option 2, but either way we need examples to be predictable in a way that allows them to be documented and tested.

CC @mcking65, @sinabahram and @IsaDC

[patrickhlauke]

the standard behaviour for <input type="range"> and how it handles PgUp/PgDown is generally down to heuristics in the browser - it looks at min, max, step and tries to provide a "sensible" number of steps - for a large range, as in this case, it defaults to segmenting the whole slider into 10 "stops" (in this case, the range goes from 10 degrees to 38 degrees, and because step is set to 0.1, browsers (both firefox and chrome, in this case...not tested safari/others), the browser chooses to ignore step, and split the range/difference of 28 degrees into 10 stops, so 2.8 degrees for each.

as PgUp/PgDown behaviour is noted as "(optional)", it could be suppressed. If not, noting that the wording in practices doesn't really specify anything other than it should results in a change by "an amount larger than the step change made by" the UpArrow/DownArrow, this would still be in line with the wording (and can be tested accordingly?).

if programmatically forcing the value to something "nicer", authors would likely need to explicitly specify what a "nice" step is - perhaps with a data- attribute on the <input type="range">, a la <input type="range" min="..." max="..." step="..." data-bigstep="...">. or take step and multiply it by some factor (but sanitise this to make sure it doesn't overshoot the whole range, and scale it down accordingly if it does)

how about, as an alternative: don't specify in the description/instruction what the big step for PgUp/PgDown actually is, just leave it at something like Increases/decreases temperature slider value by a larger amount...

[jscholes]

@patrickhlauke

If not, noting that the wording in practices doesn't really specify anything other than it should results in a change by "an amount larger than the step change made by" the UpArrow/DownArrow, this would still be in line with the wording (and can be tested accordingly?).

ARIA-AT tests are explicit about the outcome that should be achieved and tested for. When assessing assistive technology behaviour, we must have a known value to assert against. So the vague notion of it moving by more than the step amount isn't sufficient.

If it can be guaranteed that the Page Up/Down step will be 2.8 in all browsers, we can test that. But heuristics are the enemy of precise testing, not least because the behaviour may change underneath us in the future. From a usability perspective, 2.8 degrees is also likely to seem completely arbitrary to most users operating a temperature control. So I maintain that the current behaviour is problematic.

[mcking65]

@jscholes wrote:

@patrickhlauke

If not, noting that the wording in practices doesn't really specify anything other than it should results in a change by "an amount larger than the step change made by" the UpArrow/DownArrow, this would still be in line with the wording (and can be tested accordingly?).

ARIA-AT tests are explicit about the outcome that should be achieved and tested for. When assessing assistive technology behaviour, we must have a known value to assert against. So the vague notion of it moving by more than the step amount isn't sufficient.

If it can be guaranteed that the Page Up/Down step will be 2.8 in all browsers, we can test that. But heuristics are the enemy of precise testing, not least because the behaviour may change underneath us in the future. From a usability perspective, 2.8 degrees is also likely to seem completely arbitrary to most users operating a temperature control. So I maintain that the current behaviour is problematic.

James, Our goal in ARIA-AT is only to test that the assistive technology behavior is appropriate. Of course, we can't test something that does not conform with standards. In addition to conforming with standards, for keyboard behavior, we expect implementations to be consistent with the APG patterns.

In this case, the browser behaviors for Page Up and Page Down are consistent with the APG slider pattern.

ARIA-AT should be flexible enough to accommodate testing experiences that vary due to browser implementation details as long as those variances do not violate any standards or explicitly contradict the APG guidance. In this case, using a heuristic to test screen reader response to Page UP and Page Down can precisely test the screen reader behavior even if different browsers vary slightly in their implementation.

Of course, members of ARIA-AT could discover and raise issues related to the usability of browser implementations of AT--related behavior. In doing so, though, I want to be careful that we don't imply that the ARIA-AT project somehow dictates how browsers should work in order to make experiences usable for people who rely on assistive technology.

If the browser implementation directly contradicted the APG pattern, then we would have an APG issue to resolve. Either the APG Task Force could work through the browser developers or Open UI to influence the browser experience, or the APG could adjust, or there could be a middle of the road solution that adjusts both.

I don't think we should add keyboard scripting to this example. With our HTML examples, we want to illustrate the accessibility you get with as little ARIA and JS as possible.

[jscholes]

@mcking65

In this case, using a heuristic to test screen reader response to Page UP and Page Down can precisely test the screen reader behavior even if different browsers vary slightly in their implementation.

I'm not sure what's being suggested here in concrete terms. If the ARIA-AT assertions for this pattern must be generalised to not reference a specific new value when it is increased and decreased, I'm not sure how that should be automated or worded for human testers. You wrote:

Our goal in ARIA-AT is only to test that the assistive technology behavior is appropriate

How should that be achieved without a reference value to test against? I.e. what is the meaning of "appropriate" if we don't know what the output will be across browsers?

If we include the notion of the value being higher or lower than it was before, that won't adequately test screen reader behaviour. For instance if the new value is 27.8, and JAWS for some reason only announces 27 or 27.7, how will the tester know not to pass the assertion?

Alternatively, are we saying that the ARIA-AT project needs to define the expected outcome on a per-browser basis for some tests, and adapt the wording of assertions accordingly? If so, the infrastructure is currently not in place to do that, because the test format only allows distinctions to be made on a per-AT level.

I don't want to suggest that the ARIA-AT project should not accommodate behaviour that is defined by browsers and therefore may differ across engines. As we move more towards testing HTML semantics as well as explicit ARIA, these questions will have increasing importance. But the facilities are not explicitly in place at present, so this may be a good use case to facilitate exploring them.

[mcking65]

@mcking65 wrote:

In this case, using a heuristic to test screen reader response to Page UP and Page Down can precisely test the screen reader behavior even if different browsers vary slightly in their implementation.

@jscholes wrote:

I'm not sure what's being suggested here in concrete terms. If the ARIA-AT assertions for this pattern must be generalised to not reference a specific new value when it is increased and decreased, I'm not sure how that should be automated or worded for human testers.

Isn't the aria-at assertion just that the screen reader announces the current value after the keyboard command is executed? The assertion doesn't have to include the value. It is the same assertion for up/down/pageUp/PageDown. We just need a setup that ensure that the value actually changes. I don't know what we assert if the value doesn't change.

@mcking65 wrote:

Our goal in ARIA-AT is only to test that the assistive technology behavior is appropriate

@jscholes wrote:

How should that be achieved without a reference value to test against? I.e. what is the meaning of "appropriate" if we don't know what the output will be across browsers?

I think appropriate is "current" in this case.

@jscholes wrote:

If we include the notion of the value being higher or lower than it was before, that won't adequately test screen reader behaviour. For instance if the new value is 27.8, and JAWS for some reason only announces 27 or 27.7, how will the tester know not to pass the assertion?

We don't need to include higher/lower if the requirement is that the screen reader announce the current value.

@jscholes wrote:

Alternatively, are we saying that the ARIA-AT project needs to define the expected outcome on a per-browser basis for some tests, and adapt the wording of assertions accordingly? If so, the infrastructure is currently not in place to do that, because the test format only allows distinctions to be made on a per-AT level.

Definitely not saying we need to have browser-specific assertions.

Hope I'm not overlooking something and consequently oversimplifying.

[jscholes]

@mcking65

Isn't the aria-at assertion just that the screen reader announces the current value after the keyboard command is executed? The assertion doesn't have to include the value.

I may just be misinterpreting your intent here. But how does a tester, human or otherwise, determine that the value voiced by a screen reader is correct if we don't tell them what it should be? I.e. if the screen reader speaks a value that differs from the previous one, but it doesn't actually represent the current value of the slider because of a screen reader bug: with the proposed approach of only asserting that a change in value is announced, the tester would have to indicate that the screen reader had passed the test, even though it had actually failed.

This was a weakeness of some early test plans, e.g. checkbox, where testers were told to uncheck and check the checkbox in a single test, and the assertion was worded as: "Change in state is conveyed". This was fundamentally not sufficient, because it didn't prepare for a case whereby the screen reader announced a new state, but not the right one. As such, those earlier plans are being reworked to be more compatible with automation (and better for it).

The only way a tester could provide any meaningful data for such assertions is to listen to the screen reader output, then inspect the element to make sure that the current state, value, etc. matched what the screen reader said. That is obviously not tenable.

Again, I may be missing something so I'm happy to talk through it further. Although this is probably not the best forum for a detailed ARIA-AT discussion, so maybe one for the CG meeting.

[mcking65]

@jscholes wrote:

@mcking65

Isn't the aria-at assertion just that the screen reader announces the current value after the keyboard command is executed? The assertion doesn't have to include the value.

I may just be misinterpreting your intent here. But how does a tester, human or otherwise, determine that the value voiced by a screen reader is correct if we don't tell them what it should be? I.e. if the screen reader speaks a value that differs from the previous one, but it doesn't actually represent the current value of the slider because of a screen reader bug: with the proposed approach of only asserting that a change in value is announced, the tester would have to indicate that the screen reader had passed the test, even though it had actually failed.

I think aria-at testers, whether people or machines, should be able to determine the correct current value.

This was a weakeness of some early test plans, e.g. checkbox, where testers were told to uncheck and check the checkbox in a single test, and the assertion was worded as: "Change in state is conveyed". This was fundamentally not sufficient, because it didn't prepare for a case whereby the screen reader announced a new state, but not the right one. As such, those earlier plans are being reworked to be more compatible with automation (and better for it).

There we changed the test itself, e.g., check an unchecked box. But, the end is the same, assert that the screen reader reports the current state. Since it is binary, the new current state is predetermined. I agree that makes knowing the precise outcome possible. I don't think that should be a requirement for all tests because it would to severely constrains what aria-at can test. This example is exhibit A.

The only way a tester could provide any meaningful data for such assertions is to listen to the screen reader output, then inspect the element to make sure that the current state, value, etc. matched what the screen reader said. That is obviously not tenable.

AX tree inspection is not the only path for a human tester. It might be the best path for a machine.

Again, I may be missing something so I'm happy to talk through it further. Although this is probably not the best forum for a detailed ARIA-AT discussion, so maybe one for the CG meeting.

Yes, this is now an aria-at discussion. I believe that aria-at should be able to test this example as is and should not place any additional requirements on it.

There is one assistive technology requirement related to sliders that I forgot about -- some screen readers have commands for changing slider value. Since those are screen reader functions, we'll need to test them in aria-at. This will get a bit complex because we will need to assert that swipe up with VoiceOver changes the slider one step and swipe up with 3 fingers changes it a larger amount. So, in that case, the change in value is one of the assertions. If 3-finger swipe up in chrome is different from 3-finger swipe up in safari, we do end up with a complex situation. With this specific example, we will run into that problem in macOS. However, VO on macOS does not have an equivalent to 3-finger swipe up unless using a touchpad; there is not a VO keyboard command equivalent to Page UP or Page Down.

[jongund]

@jscholes
Are you saying that the ARIA-AT project could not test a standard range input element when it is not using aria-valuetext, because the change in values for Page up and Page down will be different based on the browser you are using?

[jscholes]

@jongund Currently, yes. That is my main concern. I do think the example would be more usable if the step for Page Up/Down was explicitly defined as 1 degree or 2 degrees, rather than 2.8 which is:

1. random;
2. inconsistent across browsers; and
3. frustratingly large if someone just wants to adjust a thermostat by some number of round degrees, which is a pretty common use case.

However that's not a hill I'm willing to die on, if it's been decided that this example is more intended to demonstrate the technical merit of a native HTML element with minimal scripting, rather than the recommended level of usability for a component in production. As an ARIA-AT stakeholder, my primary aim is to ensure testability, and I welcome the opportunity to discuss possible ways to address the concerns outlined in this thread.