- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Thu, 6 Dec 2018 15:41:09 +0000
- To: public-mobile-a11y-tf@w3.org
Adding a few thoughts to Detlev's rundown: On 06/12/2018 14:45, Detlev Fischer wrote: > My quick feedback before the meeting (sorry for not being able to attend > the last two): > > *Target size for mobile/tablet screen size - targets must not be smaller > than X* > DF: I envisage the same endless discussions we had in the gestation of > this SC during 2.1- not looking forward to enter that again. I think it > could live on as AAA SC and best practice Agree. The situation hasn't changed - it's still impossible for authors to accurately define a particular physical size, and one of the big problems I recall we had was that we needed to come up with various contortions to allow for situations where not all actionable target sizes needed to meet minimum size (a la "if it's part of a paragraph" etc). Fundamentally, the problem as I see it is that even the guidelines from Google, Microsoft, Apple only suggest/recommend minimum sizes, and then usually temper this further by suggesting only "important"/"primary" controls need to follow this. And that's too vague for a binary pass/fail testable assertion. If there's scope for less binary, and more nuanced, criteria in future, then sure this can be revisited. > *Spacing between touch targets - set a minimum number of pixels between > targets* > DF: I see this as closely related to the above - what is now 2.5.5 > Target Size - huge targets don't really need space between them, small > ones certainly do... Not sure this deserves a separate SC, but worth > discussing. I think at some point we discussed a minimum distance between the center points of adjacent targets (note: not just "touch" targets, let's not fall back into that trap). This may circumvent the more fiddly problem of saying "if they're small, they need a gap; if they're large, they may not". > *Provide clear indication that elements are actionable* > DF: I see losts of grey areas rising up here, menacing like ghouls from > a morass - it's related to conventions (e.g. "blocks with rounded > outlines are buttons"; "little triangles change table sorting order or > open drop-downs" etc.) and these are subject to change and difficult to > pin down Agree. It either becomes very vague (similar to the "visible" indication of focus in 2.0...which we're still debating to this day), or overly specific/restrictive (which would lead to authors/designers summarily ignoring this). > *Concurrent Mechanisms 2.1* > DF: From Kim's text I do not fully understand the issue - worries me if > I think of testing.. > > *Motion Actuation 2.1* > DF: Should we not tacle this when there are clear use cases that other > sensor input excludes certain users? All examples I have heard so far > are either motion or orientation-related or not really applicabe > (temperature, position, step sensor etc.) Any examples? > > *Different content when portrait / landscape so user can miss out on > content , this is not about same content adjusted by reflow (TPAC > discussion)* > DF: This could be a problem for all - i.e. no specific accessibility issue? If particular content/functionality is only available in one orientation, or only through requiring users to change rotation, then users with hard-mounted devices will be affected more (the rationale for the current orientation SC). > *Indication of gestures with e.g. icons, touch and/or device movements* > DF: I do not understand this (was not part of the discussion) This goes dangerously, in my view, into mandating particular iconography/design. Similar to COGA's attempt at standardising icons at some point? I think this would overreach a bit into mandating a specific design (and, as above, would risk alienating developers/designers). > *Focussed elements disappearing under sticky headers/footers* > DF: Is the idea to outlaw sticky headers? Even though I stongly dislike > them they can have advantages too, so this is a tradeoff. But there may > be clever way to ensure focus is always vissible (with JS setting > scrolling) - sounds a bit hacky to me Isn't this sort of scenario already covered by focus visible? At least that's usually where I've filed this sort of issue (i.e. "due to the sticky header, when users navigate to X, their focus is behind the sticky header and thus not visible"). > *Focus management when zooming / rotating / deleting elements* > DF: I see the case but this sounds very specific - I would clearly > separate good practices for handling focus when inserting / deleting > elements, from aspects related to zooming and the kicking in of > different CSS through media queries > > *Custom gestures not preserving default / breaking touch* > DF: haven't the time before meeting to look that up no - not clear I > understand > > *carousel example, not clear ING, buttons / slides etc., roledescription* > DF: Are you calling fo a role=carousel with sub-roles for browse > buttons, dot indices etc? You'd hope developers would soon forget about > this element... > > Don't quite understand the rest.. will try to catch up! > Detlev > > Am 03.12.2018 um 16:43 schrieb Kim Patch: >> Greetings! >> >> The next Mobile A11y Taskforce meeting will be this December 6 >> Thursday, at 11 AM Eastern (Length: 1 hour). For your local time, >> please use World Clock: http://tinyurl.com/lloxd6p. >> >> HEADS UP: Before the meeting please take a few minutes to look at what >> we have so far on the Proposals page of the mobile SCs assessment >> spreadsheet and add topics for discussion – anything that you think >> should be considered for 2.2 or Silver >> https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit?usp=sharing >> >> *WebEx, call in and IRC information:* >> https://www.w3.org/2002/09/wbs/66524/telco/ >> >> *Agenda: * >> 1. Gap analysis – discuss proposals forfor 2.2 / Silver. >> https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit?usp=sharing >> >> Thanks! >> >> Kim & Kathy >> >> Mobile Accessibility Taskforce Co-facilitators >> >> -- >> ___________________________________________________ >> >> Kimberly Patch >> (617) 325-3966 >> >> PatchonTech.com >> @PatchonTech >> www.redstartsystems.com <http://www.redstartsystems.com> >> - making speech fly >> ___________________________________________________ > > -- > Detlev Fischer > Testkreis > Werderstr. 34, 20144 Hamburg > > Mobil +49 (0)157 57 57 57 45 > > http://www.testkreis.de > Beratung, Tests und Schulungen für barrierefreie Websites > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virenfrei. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- 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
Received on Thursday, 6 December 2018 15:41:36 UTC