See also: IRC log
<kathy> regrets henny
<kathy> regrets chris
<kathy> regrets David
Kathy: I do think there's anything special we need to do under 2.3 for mobile
Patrick: agreed – no extra needs
Kathy: we don't need to talk about getting into the new mobile stuff here. 24.1 bypass blocks – anything
Patrick: nothing beyond desktop – navigate by landmarks. Skip links – we've hit problem with bootstrap where chrome gets confused about what you want to do. I filed a bug with Apple – Safari has some bizarre behavior with skip links. Technically there are some problems but in principle skip links from desktop should work on mobile as well
Kathy: I agree
... we had one under multiple ways – include shortcuts to jump.
I'm surprised that's not in there already as a technique
because it's not just mobile
Patrick: I'm not sure it needs to be called out – it would apply to users on the desktop
Kathy: I think we need to remove
M 12
... 2.4.6 headings and labels – mobile relying on labels
Patrick: even though there's
nothing here at the moment – Kathy's point about placeholder –
that that shouldn't be used – I would be for writing a
technique or flagging it in a note – something along those
lines
... I know some work is being done or at least discussions
around this topic in the HTML working group. I think it
includes some form of note the placeholder should be replied
upon as the only label being used
... I'm happy to take that one to explore possibility of
including something in WCAG about the use of placeholder is the
only way of labeling– applies not just to mobile what to
desktop as well.
<scribe> ACTION: Patrick to explore possibility of including technique/note about the use of placeholder as the only way of labeling 2.4.6 [recorded in http://www.w3.org/2017/02/02-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-62 - Explore possibility of including technique/note about the use of placeholder as the only way of labeling 2.4.6 [on Patrick Lauke - due 2017-02-09].
Patrick: 2.4.7. Touch focus isn't as important as keyboard but provides positive reinforcement. There are techniques to make sure that, say links that are clicked do show an actual outline or some kind of focus state as they are being activated. In principle it would be good to have that. I can provide some material for it
<patrick_h_lauke> https://gauntface.com/blog/2013/12/09/focusing-on-the-web-today
Patrick: some kind of note just because just because it's a touch device, doesn't mean focus is not important. Visible focus styling is also important ontouch devices or devices that don't use a traditional keyboard – that could go into understanding – focus visible
<scribe> ACTION: Patrick to at least contribute to M001 under 2.4.7 [recorded in http://www.w3.org/2017/02/02-mobile-a11y-minutes.html#action02]
<trackbot> Created ACTION-63 - At least contribute to m001 under 2.4.7 [on Patrick Lauke - due 2017-02-09].
Patrick: 2.4.8 not sure how this
is different than what you would do on a desktop
... nothing specific is coming to mind – just another way of
doing navigation for small screen but it doesn't sound like
it's specifically a technique that we want to show as a way of
providing this
... M015 – not thinking of a technique specific to mobile
... 2.4.9 – nothing
Patrick: 3.1.1- 3.1.6 can't think
of anything that's not already covered
... nothing mobile specific that we need to add
Patrick: 3.2.1 is less of a problem on touch, or applies the same way on touch – just because it's a touch device would still want to avoid triggering things on focus. May want to add a note, but maybe not, don't want to scatter notes in understanding
Kim: issue with focus is if the input isn't touch, focus may act differently because touch automatically focuses (similar to the mouse on the PC). This is especially apparent with speech input. The question is whether it's different in mobile/touch, or there something specific for mobile/touch – an extra warning. But I agree that we don't want to scatter notes all over the place
Jatin: do we need ontouch
Patrick: just looking at what's
currently here – what we can put in existing SC's
... 3.2.3 doesn't talk about hamburger menu type
expand/collapse but beyond that the principal is already there
so potentially it could be written as another technique, but I
wouldn't push for it
<patrick_h_lauke> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G61
Patrick: there's no code, just in
prose. The only sufficient technique for current 3.2.3. We
essentially want to say roughly the same thing just hamburger
menu make sure things are in the same order – I don't think it
needs a new technique just to say that this also applies when
it's collapsed in a single icon like a hamburger menu
... so I'd say leave the mobile navigation bar one aside and
lost somebody has a burning desire to write something
... conceptually it's the same as desktop– of what were trying
to say here is inside what comes up when you trigger it, the
order is the same that you should already be thinking about
that in desktop so would probably feel weird if we single it
out as an example – something like a mobile smallscreen
collapsed navigation. so I would be in favor of dropping this
technique
Jatin: agree, recommend dropping navigation bar example
Patrick: orientation order – may
not always be the case that for a small screen device for
instance you may choose one way of navigating the site which is
very different from what you would do on a larger screen
desktop
... so I'm not sure system navigation is a success criteria in
the moment applies. I think the important thing is as you stay
within your screen size it stays consistent, but between those
as well probably goes beyond what the SC itself is requiring.
Part of that technique would be covered in the change of
orientation, how things change when you go from portrait to
landscape. I don't...
... think the current spirit of 3.2.3 covers across devices as
well
<patrick_h_lauke> i.e. it needs to be consistent WITHIN one particular size, but not consistent even when switching between different sizes
Kim: so it goes too far for the FC, or it's not necessary in general
Patrick: not necessary at this
point
... the way I read it it says they should remain consistent and
I don't think that's the case that 3.2.3 applies because what
you go past a certain breakpoint it would be a different case –
the consistency part can't go across versions. That's just a
natural thing that won't happen. So proposing that technique
implies something that I don't think it does
agree that 3.3.1 nothing extra in mobile
Patrick: 3.3.2, agree with M005,
not sure about M021
... M
... M005 would also be good to discuss what kind of
instructions we have in mind – text, how to word it or orderly
dialogue – verbiage point of view or here's how you can
provide, tap, bring up descriptions. Seems to be the
latter.
Kim: discussions for next time: covering across devices iimplication not fitting into 3.2.3 and making M005 more clear
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Present: patrick_h_lauke Kathy Kim Jatin Regrets: Henny Chris Jonathan David Found Date: 02 Feb 2017 Guessing minutes URL: http://www.w3.org/2017/02/02-mobile-a11y-minutes.html People with action items: patrick[End of scribe.perl diagnostic output]