Meeting minutes
2.4.11 - Focus Not Obscured (Minimum)
<Joe_Humbert> w3c/
Jamie The content itself seems straightforward. Things to think about: How is this different from focus visible? What is obscured but still allowed? There could be questions raised about how this plays out in real practice. What does it mean as a concept?
Illai On mobile, not so much web, in many cases you have elements receiving focus that should not be part of the page / screen - while using keyboard it makes sense
Joe_Humbert Are there any stats on keyboard usage? (He did say he supports the idea :) ) How prevelant is it?
Joe_Humbert do mobile OS use the same HID interface - is it the same as desktop
Devanshu In my opinion and experience - the problem is that there is no stats and that is the main problem. People do ask about keyboard accessibility. There are a lot of companies making these devices, but no standards seem to exist
Illai I didn't mean refer to keyboard - but we should try to rephrase that we should not focus on keyboard for this criterion
<quintinb> +1 Illai
<Karla> +1
Jamie What do folks think about the addition of a layer that includes voice control and voice access, but focus on the audience that needs this type of focus? Is this about things that have access focus?
Jamie voice users may have issues with this because the component under "focus" is actually obscured by something else
Joe_Humbert should we replace the word "keyboard" in everwhere or just in this criteria
Illai we should look at the context of each one
I think we could call it "Input focus"
Jamie 2.4.11 could say "When a keyboard operable component receives focus" - this about the component that has focus. The question about which type of focus is unclear. People may consider this verbose or get overly literal with the language.
2.4.11 - 2.5.7 Dragging Movements
<Joe_Humbert> w3c/
quintinb are we allowing for non-pointer movements (keyboard shortcuts / actions)?
Joe_Humbert this does encompass that (single pointer)
Joe_Humbert I don't think this should be the developers issue, this should already be put in place by the OS
I think any custom gestures defined by the developer is a business risk not having alternatives (because gestures aren't discoverable)
ack \
Jamie reminder to the group that there is an open question on dragging movements - it is linked. So there is a reference
<Joe_Humbert> dragging movements definition discussion w3c/
Jamie I feel like that we could just keep it the same, but remove web
<quintinb> +1 Jamie
<Illai> +1 amie
<Karla> +1
<Illai> +1 Jamie
Joe_Humbert we may have to redefine "user agent"
<Jamie> +1
<Jamie> to myself...?
Jamie: D
<Joe_Humbert> redefine "user agent" w3c/
<Joe_Humbert> +1
ACTION: Propose to accept 2.5.7 as written in WCAG2ICT
2.5.8 Target Size (Minimum)
<Joe_Humbert> w3c/
I think this is actually large considering there's no "unit standard" - Illai's MCAG does a great job at that
<Jamie> +1 Illai
Illai Both Android and iOS recommended sizes conflict with web - adopting 24x24 isn't sufficient
Google also has different sizes based on where elements exist on the screen: https://
Joe_Humbert we could add a strongly worded note that 24x24 is too small practically for human fingers
How does this apply to links in mobile? (Just a point of interest ask)
Jamie 1. in testing context, folks don't have access to the exact numbers (@Joe has a solution - Google Ally scanner (Quintin adds the Android Debug Bridge 'uiautomator dump')) 2. In practice this is most an exception because of spacing
https://
Joe_Humbert we could refer to the bounding box for the hit target size
<quintinb> +1 Joe_Humbert
<Illai> +1 Joe_Humbert
<Jamie> i have to drop, thank you
ACTION: Add a note to 2.5.8 about a larger sizing requirement looking at the AAA requirement