Meeting minutes
First Public Working Draft (FPWD)
JJ shared the current status of the WCAG2Mobile draft.
JJ asked the larger group to leave comments on the github
So we need to finish the issues in "drafting" section
Key terms section is pending.
JJ plans to publish this in early March
<JJ> CFC in February
2.4.3 Focus Order
Aash shared that the default flow should be derived from research. Can be a note
Detlev we can't assume that we can reach all elements by tapping / swiping
@detlev if you can reach elements by any means, the issues is pass, but with a note
JJ we need to understand about the nuances of iOS and Android
Jamie we need to maybe differentiate the interactions in keyboard vs non-keyboard
JJ we had an idea to update keyboard interface definition to include all assistive tech
JJ mentioned that keyboard + AT need to be mapped properly as they might interfere with each other
ACTION: Update "navigated sequentially" definition, it mentions "keyboard interface"
ACTION: Define the ways of interaction, e.g. tab, shift+tab, arrow keys, etc. that are acceptable to navigate
Detlev we can define one way where all elements can be reached with the same interaction, arrow or tab
ACTION: Think about what "sequential" means in a mobile context in relation with the keys used for navigating
Detlev the special keystrokes needed to go to navigation / header might not be known to all.
Jamie Agree with Detlev . Special keystrokes may confuse people.
Jamie the tester needs to know how the keyboard interacts with the operating system
ACTION: Consider adding Note that failure depends on whether the expected keyboard operation matches the actual keyboard operation of the component / screen
<julianmka> +1 Jamie
Jamie we may add a note about keyboard functionality . That will help reduce confusion
<JJ> julianmka: Take semantics of the view into account to define the expected keyboard operation keys
<julianmka> Workday's research on keyboard nav in mobile: https://
<Detlev> julianmka I was not suggesting that expectations should be overwritten, sure
<julianmka> Apologies for the misunderstanding Detlev
we can mention the accepted ways of using keyboard based on comments from julianmka and Jamie
JJ the guidelines with medium / large variation, we may have to work more to clarify
2.4.11 Focus Not Obscured (Minimum)
<Detlev> presnt+
Detlev 2.4.11 is not included yet in testing since EN does not include them
Detlev there needs to be some differentiation between keyboard and OTHER interfaces
<Jamie> prsent+
Jamie we clarified that the component in focus needs to be visible, not the focus
ACTION: Clarify "author-created" definition (maybe in AG WG?)
Jamie to clarify this on github
<Detlev> addition to minutes: Of course you **can** include 2.4.11 in testing - it's just we don't currently, due to the current content of EN 301 549 V.3.2.1
<JJ> Joe_Humbert: mentions scenario where the focus indicator is displayed visually at the top level, but the actual component that is attempted to be indicated is on a lower level (Z-index)
<JJ> Jamie and Joe_Humbert both mention sticky component that could also obscure content (not very common in apps)
<julianmka> I've seen the same thing as Joe's first example on app screens with shoddily-implemented modals that didn't limit focus to the modal/sheet.
<JJ> JJ: Floating action button could potentially obscure content, usually fixed in bottom right position
Joe_Humbert the ATs on mobiles have been there since the beginning. Should we be considering these, mapped to keyboard interface?
JJ if it is written as keyboard, we consider only keyboard. For keyboard interface, we consider others
Jamie when scrolling, the sticky header/footer turns a bit translucent, where the sighted users can detect the element in focus
<JJ> Jamie: how to deal with semi-transparent (semi) sticky components that might change opacity while scrolling? When is something "not entirely hidden"?
Jamie we need to document the percentages of visibility if content is moving behind translucent sticky elements
<Jamie> @Aash just a modification: I didn't intend to suggest that we need to document the percentage of opacity for visibility
<Jamie> JJ