WCAG Feedback

3.1 Keyboard Control for Touchscreen Devices

Ensuring keyboard control for all functionality Ensuring touch access control for all functionality Ensuring that users are not trapped in content (using touch and keyboard) Defining the hover, focus, selected and touch (regular, long) states Use focus, hover and select states consistently and in a way that follows the respective platform conventions

Questions:

1. Does each technique make sense to you? (for now these are just titles, so it can be a challenge to be certain)
2. Do you agree that the referenced success criteria is applicable to each suggested technique, or that the technique is applicable to the SC)?
3. Do you think that there is another technique that this might better be an example for instead of a technique on its own?
4. Do you think that each is likely to be sufficient or advisory?
5. Are there other techniques that you can think of that address the SC in the mobile space?

Discussion

4/20/2015

I agree and I’ve documented this. There are actually additional ways using fixed positioned content that developers can prevent access to page content when pinch zoom is used. Thus, it makes sense to have a specific failure for viewport scale restriction but also an additional failure for other techniques that prevent text resize.

- Jonathan Avila

4/20/2015

We may have this but I want to þe sure we have a failure if the application overrides the pinch zoom or other native zooming capacity..

- David MacDonald

____________________

4/20/2015

For me, this is an issue about comparable access. For example, if a mobile fitness app was accessible with the keyboard but not with the touch gestures of a mobile screen reader such as Talkback blind users would be required to carry around a physical keyboard with the mobile app. In many situations this is unreasonable and if the standard user isn’t required to use a keyboard forcing users of screen reader to use a keyboard is not comparable access.

- Jonathan Avila

4/20/2015

Many great points Gregg. I think that one of the points that you raise might be solved if the second bullet was reworded as something like: Ensuring touch access control for all functionality that is not already operable by physical controls on the device.

GV: Hmm. if advisory that is ok. This language wouldn’t cover audio-only communicators (like emergency call buttons or future communication buttons like the badges on star trek. Keyboard interface access is still possible for those via bluetooth or equiv (which the device will probably already have in order to to work) but touch access is restricted to just a single touch sensor

We don’t have star-trek communicator badges, but we do have emergency call buttons that could use touch and voice to control them.

What is the concern about providing touch access to everything non-physical. We already say they can’t use voice alone for any functionality. Would that not get you to the same place? (I thought I thought of an example but can’t remember now. can you think of one?)

Maybe the second part of this could be written as an exception to the original simple requirement – but a single sentence may be the most direct way to express things.

GV: Can you give me an example of what you mean?

I think that your offer of some words to clarify the need for keyboard control on all touchscreen devices would be very useful. In my limited experience I have found that people unfamiliar with WCAG 2.0 always interpret keyboard control in the context of: - either a keyboard on the device; - or situations where a conventional keyboard can be attached to the device; - and almost never in terms of other assistive technologies capable of generating keystroke input.

GV: I think you are spot on with this observation.

I’ve even seen hints of this confusion in some WCAG discussion threads!

The WCAG 2.0 term “keyboard interface” can also mislead engineers who may have come from a hardware background as they tend to immediately think in terms of things like Bluetooth, RF, PS/2, etc..

GV: ah - they think of the hardware interfaces but not the software ones. Good thought ( The Bluetooth interface though is the primary one for touchscreen only devices to provide physical keyboard and alternate keyboard access. )

Some helpful explanatory words might ensure that nobody can misinterpret the intent of this important requirement.

- Michael Pluke

____________________

Apr 17, 2015 Perhaps some text that we wrote in the European equivalent of Section 508 (EN 301 549) in relation to closed functionality might help with the trapping issue. The relevant text is:

“Where input focus can be moved to a user interface element, it shall be possible to move the input focus away from that element using the same mechanism, in order to avoid trapping the input focus.”

This is very generic and would apply to moving the focus using touch, voice, or any other means. - Mike Pluke

17 April 2015

[Gregg wrote] ØEnsuring touch access control for all functionality Ø Hmmmm. I think this is hard. For example — where you have physical toggle keys (e.g. the sound/off switch on the side of the device) how would you toggle that physical control from the screen. And if you did - then the switch on the side would show the wrong status. iOS has assistive touch which lets you control the same options that are toggled by the physical phone controls. For example, with assistive touch you can mute or unmute the phone by touching the assistive touch options and it will actually override the controls on the phone. That is even though the phone’s toggle is on mute if you turn Assistive Touch’s to unmute it will be unmuted! So yes, this is very possible is used today. ØEnsuring that users are not trapped in content (using touch and keyboard) ØFor keyboards this is handled under a different SC ØFor touchscreens I don’t think I would list this (here nor under the “TRAP” SC) unless you can think of some way that you CAN trap someone with a touchscreen. When VoiceOver is active you could trap someone. For example, a native app could be designed to not support explore by touch by not using accessibilityFrame properly but it could still support swiping but trap the user when swiping. This might be more difficult for web pages – but perhaps you could trick the explore by touch feature by using overlaid content with different z-indexes.

- Jonathan Avila

April 14, 2015

1) Does each technique make sense to you? (for now these are just titles, so it can be a challenge to be certain)

GV: <start>

Ensuring keyboard control for all functionality YES - with WCAG exceptions of course.

Ensuring touch access control for all functionality Hmmmm. I think this is hard. For example — where you have physical toggle keys (e.g. the sound/off switch on the side of the device) how would you toggle that physical control from the screen. And if you did - then the switch on the side would show the wrong status. Home button is another one.. but that COULD be made available.

I think that as an advisory it is fine.

Ensuring that users are not trapped in content (using touch and keyboard) For keyboards this is handled under a different SC For touchscreens I don’t think I would list this (here nor under the “TRAP” SC) unless you can think of some way that you CAN trap someone with a touchscreen.

Defining the hover, focus, selected and touch (regular, long) states Use focus, hover and select states consistently and in a way that follows the respective platform conventions

Not sure I understand this one - what does it mean? I presumed they are defined if code is written implementing them. Do you mean explain?

GV: <end>

2) Do you agree that the referenced success criteria is applicable to each suggested technique, or that the technique is applicable to the SC)? GV: I don’t think 3.1 applies to touchscreen. But as advisory I think you could attach touchscreen items here.

3) Do you think that there is another technique that this might better be an example for instead of a technique on its own? GV: Hmmm. Interesting thought. Nothing comes to mind.

• Ensuring keyboard control for all functionality This one of course IS SC 2.1.1

• Ensuring touch access control for all functionality This would not be an example of any technique I know of.

• Ensuring that users are not trapped in content (using touch and keyboard) For touch I don’t think it makes sense. At least I have never heard of or seen it. For keyboard it is already SC 2.1.2

• Defining the hover, focus, selected and touch (regular, long) states again Im not sure I understand what this means exactly.

• Use focus, hover and select states consistently and in a way that follows the respective platform conventions This one should be attached to SC 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification

4) Do you think that each is likely to be sufficient or advisory? All are advisory.

The keyboard aspects of two are SC - so not really techniques. The rest don’t satisfy any SC so they can’t be sufficient.

5) Are there other techniques that you can think of that address the SC in the mobile space? No. But a good explanation is needed to people understand the importance of access via keyboard interface on a device that has no physical keyboard.

If you don’t have one - I could help put one together from notes around the time this was done — but with special emphasis on Keyboardless devices.

- Gregg Vanderheiden

Apr 13, 2015

If "Keyboard" control is very important for Touchscreen Devices, it should have a clear definition, imagine touchscreen device is ATM, watch, GPS, this is not always make sense in general keyboard definition.

- Kenny Zhang

3.2 Touch Target Size and Spacing 28 April, 2015

Providing adequate touch target size / Ensuring that touch targets are large enough to touch accurately without magnification Provide adequate spacing between touch targets

Questions:

1. Does each technique make sense to you? (for now these are just titles, so it can be a challenge to be certain)
2. Do you agree that the referenced success criteria is applicable to each suggested technique, or that the technique is applicable to the SC)?
3. Do you think that there is another technique that this might better be an example for instead of a technique on its own?
4. Do you think that each is likely to be sufficient or advisory?
5. Are there other techniques that you can think of that address the SC in the mobile space?

Discussion

4/28/2015

keep going…..

what do you mean by break points how does (any but the most sophisticated author programmer) know when different breakpoints are reached e.g. how do my students who have never programmed a web page before know how to do this? if the small size is good enough for the first break point — why isnt it large enough for the third. if they goal is just “as large as you can reasonably make them” then it shouldn’t be a requirement - but a recommendation (advisory) - no? I WCAG we made assumptions about some things. (e.g. if you had low vision - and needed very large text — you wouldn’t use something with a very small screen and expect the authors to be able to present content where only one or three words fit on the screen at a time…

not sure of the answer here but if we don’t have something as a stable rationale for the size— and we don’t require a real size — then I think we are just recommending that things be as large as practical.

hmmmmmm. other thoughts anyone?

- Gregg Vanderheiden

Apr 28, 2015

If there were break points there could be different requirements for each one... so it could be x%, y%, z% based on the break point. I actually like better the idea of having actual size minimums based on break points which was my second suggestions in that email. - David MacDonald

Apr 28, 2015

Not sure I understand

How does a requirement for a percentage ensure that people with physical disabilities would be able to use something.

and why should someone with a 24 inch touchscreen have to create content with buttons that were 20% of the screen (monster buttons) when 20% of the width of an iPhone 4 screen would be very small buttons for someone with a physical disability.

Am I missing something? - Gregg Vanderheiden

Apr 28, 2015

It possibly could be percentages?

Or

we perhaps better, we could define several screen size ranges and base dimensions on those screen sizes. -If a screen is between x by y size and W by Y dimensions then buttons size would need to be A and B and space between links would need to be -If a screen is between W by X size and dimensions then buttons size would need to be B and C... etc.

I think if we treat it like common responsive design break point ranges we could come up with common screen sizes (e.g. Small mobile, big mobile, tablet) and actually give some concrete advice for each of those sizes, which could be measurable and therefore a success criteria... I think if we are going to do something useful for authors and policy makers, we have to be more clear than the measurement of "adequate". - David MacDonald

Apr 27, 2015 David, I don’t see how they can ever be success criteria - since we would have to specify physical dimensions — and we don’t know the device size. are you thinking we assume this is a tablet or something and base all recommendations on that? With some set resolution? Or do we assume that we can rescale content to force a physical size regardless of screen size and resolution?

What are your thoughts? Gregg Vanderheiden

____________________

Apr 27, 2015

It would be nice to choose wording that could eventually become a success criteria rather than techniques. The principles of enough space to click without hitting something else, and a big enough target seem foundational. The word "adequate" is pretty subjective, I wonder if there is a range of measurements we can provide as were discussed at the face to face. - David MacDonald

____________________

04/16/2015

Gregg wrote: "Of course these minimum guidelines are not used for their keyboards.”

True, but they have some pretty good algorithms for working out which key you meant to press, automated correction or word suggestion and in some cases alternative keyboards or voice input.

"It still seems strange to me that we are suggesting that interfaces should be at least 9mm to accommodate people with physical disabilities….. "

Circling back to the original question (which I see has been updated already [1]), in a web context I think you could specify 44px x 44px (in CSS pixels, not device pixels), but I admit that needs some testing.

Perhaps a line could be added underneath the best-practices to say something like “For web content on mobile devices 9mm is approximately 44px in CSS units.” It is not practical for a web developer to know the sizing of 9mm across devices, and often triggers the kind of discussion we’ve just had!

If you meant that it is odd we specify a size for people with disabilities that is the same as the general population, then I would perhaps phrase the size point as: "Ensuring that touch targets are at least the size specified in the mobile platform guidelines."

Then explain that the platform guidelines generally specify 9mm high by 9mm wide, which translates to 44px by 44px.

In the context of a browser, they have already had to make the decision about how big is big enough, and that is the size of pixels.

I’m still not convinced about second best practice: "Ensuring that touch targets close to the minimum size are surrounded by a small amount of inactive space."

Although it is technically true, the times where it matters are when you have navigation bars or buttons that are visually together.

If you have two buttons that are visually next to each other with no gap, should the developer shrink the size of the hit area so it is less than the visual appearance?

I think that would be counter productive. If the user touches the interface and nothing happens because they went in the gap, that is probably worse than the UI guessing which option they meant.

Kind regards,

-Alastair

1]http://w3c.github.io/Mobile-A11y-TF-Note/#touch-target-size-and-spacing

____________________

4/16/2015

All of the touch discusssion on size and space should also consider the touch and explore or touch to read of items that may not be links or buttons but checkboxes and text field as well. I've recently run into a testing situation where a basic web checkbox is presented on an iPad Mini 2. The target size for the check box is is extremely small. Focus is not consistently put on the checkbox but rather the label is read instead. Since the iPad and Android do different things with the checkbox and labeling, they may not have the same associativity as found on larger devices (PCs) with their respective screen readers and keyboard navigation. This is a very important thing to get right and I appreciate everyone's insight and conversations. - Regards. Alan

4/16/2015

While creating sufficient techniques is great, please consider validation methods as well, e.g. creating a very untestable, or subjectively testable technique creates inconsistency within the development lifecycle. If using actual units of measure, e.g. 9MM, beyond using a ruler or electronic ruler tool, I’d like to know what people think is an efficient validation process as well. From my own personal experience using mobile screen readers I can say that very small active areas can be challenging, but that if the item is correctly within the “focus order” it is less an issue. For people who are not using sequential navigation of focusable elements this doesn’t help, but certainly could be a mitigating solution for small active areas onscreen. However, again, please consider the validation technique when suggesting sufficient techniques, especially since we really won’t know if a technique is actually sufficient without an agreed upon validation method. Allen Hoffman

April 16, 2015

Thanks This is great info. Of course these minimum guidelines are not used for their keyboards. but this is good info.

It still seems strange to me that we are suggesting that interfaces should be at least 9mm to accommodate people with physical disabilities…..

Gregg Vanderheiden

Apr 15, 2015

Hi Gregg, You wrote: “But my bigger concern is that there is no platform guideline for buttons.”

AC: That isn’t true for mobile [1], Apple, Microsoft and Google [2] all specify a minimum size.

They (MS & Google at least) also try and do that in a DPI-agnostic way (Dots Per Inch) that comes out at around 9mm. Apple does so in a DPI-agonistic way they call “points”, which is the same as pixels on a 160DPI (low res) screen.

From the Android guidelines: “On average, 48dp translate to a physical size of about 9mm (with some variability). This is comfortably in the range of recommended target sizes (7-10 mm) for touchscreen objects and users will be able to reliably and accurately target them with their fingers.”

Where dp = “density independent pixels”, and 1dp = 1 pixel on a 160dpi screen. Apologies for the acronyms in this area, it is a minefield.

All of the major platforms have a variety of size devices with varying sizes, so they have methods of defining sizes in device-agnostic ways.

So it is not correct to say “And even an iPhone button is indeterminate since you don’t know which iPhone it will appear on.”. Developers can specific ‘44 points’, which would be 44px on an iPhone 3GS, and 88px on an iPhone 4/5/6.

You might think that it is one thing for apps, but how does that affect the browser? Browsers also have to pick a “CSS pixel” size, so a device that has a high density screen doesn’t render everything in tiny text.

For example, I used to have an HTC One, which is a 4.7” screen with a resolution of 1080x1920 (469dpi). The default width for a website in Chrome was 360px, not 1080px, as they choose a CSS pixel size 3 times larger than the screen pixels. Interestingly, when I used Firefox the default was different, I think 330px or something.

So when you say “Web pages for example have no idea what size they will render at.”, that is sort of true, but thanks to years of 1000px wide websites and various devices having to cope with them, the CSS pixel is a remarkably reliable way of specifying sizes.

As I mentioned before pixels sizes are probably the best cross-platform method of sizing [3], and given these are mobile guidelines and therefore within arm’s length, you could probably set 44px as a minimum size. (That needs some testing, I think it will be a consistent figure I’m just not sure 44px is it.)

However, I still think advising people to use the platform guidelines for minimum sizes would be the best approach, perhaps with some advice on how that translates to the web.

Kind regards,

-Alastair

1] http://www.lukew.com/ff/entry.asp?1085 2] http://developer.android.com/design/style/metrics-grids.html 3] https://alastairc.ac/2013/02/how-to-hold-your-ipad/

____________________

4/15/2015

Ok better.

But then should we say font sizes should AT LEAST be 10 point to prevent it from being smaller than recommended minimum for text? I don’t think that will be very accessible to many.

I think the same applies to size.

But my bigger concern is that there is no platform guideline for buttons. Web pages for example have no idea what size they will render at. And even an iPhone button is indeterminate since you don’t know which iPhone it will appear on.

I’m not sure we can set requirements on size.

That having been said — I note that you said “advise” not “require” which addresses my last point.

Still if it is advisory - couldn’t we ADVISE that they make the buttons as large as possible given layout, function and aesthetics — and that they have an option to make them larger than aesthetics for those that need them?

(Thanks for pushing on this )

Gregg Vanderheiden

Apr 14, 2015 Sorry, I didn’t put that very well.

If we advise that targets are at least the size specified in the platform guidelines, that prevents people making targets that are too small but people without disabilities are just about be able to use them.

I can see instances where someone tries to cram in lots of options making the hit targets very small, having a guideline/SC/advisory could help people to argue for larger hit areas.

Kind regards, -Alastair

Tuesday, 14 April

Hi I think I am reading this wrong. But it sounds like we are determining what the size for a person with a disability is by defining it as "the minimum size that is recommended for people without disabilities? But in any case it should not be bigger than normal?"

that doesn’t grok. So maybe there is an error below or in my logic above.

( I concur that we can’t specify that everything have larger than normal buttons or that all button be larger than X (imagine fitting the keyboard on screen of a phone if they keys were of any significant size). So I concur with your rational approach. But I think that this provision (and many others) are “general direction” guidance, and not something that can be more than” “Do XXXX as much as you can and in as many places as you can” rather than “do this” in general or "you must do this” thx - Gregg Vanderheiden

Apr 13, 2015

Testability is difficult for this one, but I can see a couple of approaches: Does the minimum size meet the platform guidelines. For example, I think iOS defines something like 44 points as a minimum (points being relative pixels, I.e. 88px on a 2x display), and Android & Windows have something similar. We pick the smallest of these as the minimum to work across platforms as a testable minimum. Given that pixels are the best relative measure across platform [1], working out a minimum physical size on a small device and working out the pixels should be possible. From a limited experience in testing with people who have mobility impairments on mobile, they tended to pick a larger phone like a 5” Android assuming that the buttons would be bigger. (This was pre-iPhone 6 / 6+). People who needed more essentially have to use an alternative input.

I think the minimum value has to work for the mainstream, i.e. not be bigger than normal, but the SC could be used to prevent buttons being too small.

If we can’t define a minimum, then it will have to be ‘should’.

Kind regards,

-Alastair

1] https://alastairc.ac/2013/02/how-to-hold-your-ipad/

4/10/2015

Hi

I think this is important

but I wonder about testability. And I’m not sure how we would determine what these mean.

This is for CONTENT — and target size is determined by they hardware. e.g. the size of the button varies depending on whether it is displayed on a 56 cm/23 inch touch screen or a 40cm/15.7in touchscreen or a 10cm/4 inch screen

In fact - what will fit on one screen would not on another

If the author has no control over what size screen it would be on — how do they follow this provision? If these are just “SHOULD” guidelines (advisory) then these are fine. I don’t see a problem/question.

but if they are SHALL then … don’t they have to be measurable? — and don’t they need to apply everywhere (all content)?

We need to think about being on the receiving end of these. If someone requires US to follow them - and will not pay our salary (fee) if we don’t. How will we know (and prove) that we have met them?

The question/concern is about about the Target Size/Spacing provision — but also for other ones as well.

So QUESTION: Is this an advisory document (all "shoulds” ) or a conformance document (you “Shall” do these or you don’t conform). If it is ADVISORY - then the “are” in the provision below needs to be changed to “should” or “is best if” or something like that.

If it is a CONFORMANCE type document then we need to say exactly how large, and say it in some measurable fashion that everyone would agree on whether it is met. “large enough” is not measurable. “large enough to touch accurately” is different for each person. Which person is the “certified test measure person” ? Ditto for “adequate" gregg

____________________

4/10/2015

From Tim Boland: Would need to think about it more.. what is adequate for one user may not be adequate for another user? Are there studies/data on the subject, or from other “size” or “space” related techniques already existing? If not, then maybe couch in functional terms, for example, establish a “minimum size” such that with the help of AT or other assistance the possibility that a user could touch accurately without magnification would be greatly increased. Or, just combine the two bullets to read “ensure that touch targets can be touched accurately without magnification”, and then go into size and space issues in examples or description.. I don’t think that by shortening it you lose the essence of the technique..

4/10/2015

Hi Tim – Do you have a suggestion for a word replacement for “adequate”? Thanks! Kathy

4/10/2015

My comment on the following bullet points: “adequate” seems subjective and not testable without further specification..

____________________

4/10/2015

Although this is being proposed for SC 3.2, it doesn’t obviously seem to have much to do with the concept “Understandable” and has little similarity to the other items in 2.4 which all relate to ensuring that the underlying logic and behaviour are “predictable”.

“Touch target” is not a defined term in WCAG, but a rough attempt could be something like “the region around a displayed control within which a touch event will operate that control”. Because it is talking about the absolute size of a region on a physical user interface, there is clearly no parallel in WCAG (which relies on a user agent to render the content and to determine its absolute size).

Alastair’s suggestion that it could be seen as being a gap in 2.4 makes a lot of sense to me. It’s definitely related to touch controls being “operable” and is close to the concept of “navigable”. But really it is quite different to the other SCs in 2.4 as they also relate to underlying logic and behaviour and not to physical user interface characteristics. I also agree with Alistair’s suggestion that the first requirement is the most important.

When creating the European standard EN 301 549, we were unable to define requirements about target sizes that could be unambiguously applied across all types of ICT including mobile devices. If wording such as “adequate” and “large enough” is considered acceptable, then the proposed text certainly emphasises that a large enough target size is an important requirement.

Best regards,

Mike Pluke

____________________

4/10/2015

Alastair, These two are being proposed for SC 3.2. AWK

4/10/2015

Providing adequate touch target size / Ensuring that touch targets are large enough to touch accurately without magnification Provide adequate spacing between touch targets

AC: For these two, I think the first is far more important. Using large targets is well established as helpful for everyone (Fiitt’s law), and whilst I can see having space between targets being helpful, it is much harder to do on smaller screens. (Thinking of the standard 'four buttons in a row' interface on many phone apps.)

To me that indicates that the first should be sufficient, and the second advisory. However, in a world of many devices and relative pixels sizing, I’m not sure how you would define sufficient? I.e. How big is enough?

In relation to success criteria, it isn’t clear from the TF note which WCAG2 SC these apply to, it points to there being a gap, probably under WCAG2 2.4?

Kind regards,

-Alastair