See also: IRC log
<Detlev> scribe?
<Detlev> scribe: Detlev
<patrick_h_lauke> https://rawgit.com/w3c/wcag21/FPWD_review/guidelines/index.html
<Kim> Kathy: there is a first public working draft. We have 10 success criteria that we went through last week that we propose to go into the first public working draft
<scribe> scribe: Kim
Kathy: those 10 are marked as being propose but they haven't been fully reviewed by the working group – caveat, everything can be changed, but we did get 10 in there last week. the ones that we took out we recommended to wait till silver based on comments in github
<chriscm> Sorry, I'm watching my niece today :)
Kathy: there's more discussion that needs to take place. Instead of trying to rush through, trying to change on the fly the decision by the chairs was to have 8-10 success criteria from each of the different taskforces go into the first public working draft so we can start getting comments and feedback on those. That's what the status is of this first public working draft. Any questions?
Marc: is there a discussion going on about folks just not wanting to change any of the existing success criteria?
Kathy: when the decision was made
about creating the Trask forces it was voted on that we
couldn't make substantial changes to any existing success
criteria. 2.1 and 2.0 stay the same with some add-ons. It
hasn't been decided that we can change them. Has wider
implications – COGA misunderstood and wrote a lot of their
success criteria to change existing instead of separate ones.
There are a...
... lot of moving pieces that really need to be thought through
– implications, what were actually going to do. Until that
decision is made we can't really move forward. originally we
were thinking of changing 2.1.1, but then there's been a lot of
thought in writing keeping at the same.
... comment – first get comment and then look at the bigger
picture – what's going to happen in silver versus 2.1. That's
where were at – there's no decisions that have been made to
date
... I didn't want us to try and rush to get something in just
because we were on the deadline for first public working draft.
We would've had nothing in for mobile because we would not have
gotten consensus within a weeks time when we had spent several
years developing it. So we will look at it again and the
working group will look at it – we'll get there.
... CSUN, Shadi Kim and I will be doing a presentation we will
be asking for comment on the working draft
... they are fine with us working on techniques for existing
success criteria and putting them in. Also changes that we
think – things like adding a technique. There's still confusion
out there about how WCAG applies to mobile
Shadi: hate to have people stalled. my understanding is techniques are a much more atomic level and will be quite movable depending on how the success criteria is formulated
Kathy: I think to a certain extent we probably could – we haven't gotten a lot of guidance from working group in how they should be written
Detlev: we started with
developing techniques and then moved to developing success
criteria, so there's one where I already did something – mobile
navigation for narrow break points – don't know whether that
could be mapped to some other existing success criteria. There
may be others
... would want to make sure work would be used. we could go
through the list and see what can be mapped on to 2.0 success
criteria right now and is safe to develop anyway. We would
probably be wise not to develop techniques for things that
would be going in 3.0 right now
Kathy: we have started going through some of those old ones – from the standpoint of what was done and what we could add and we've got a bunch of actions were were going to be writing techniques or modifying techniques to go into WCAG 2.0 or 2.1, so we have a clear picture of what we can start working on
<Kathy> http://w3c.github.io/Mobile-A11y-Extension/
Kathy: going through determining whether we should keep them in or remove
We left off on 3.3
<patrick_h_lauke> https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html
Kathy: labels required – that's for everybody not just for people with disabilities
Patrick: adding touchscreen here – clearly stated how the user should act with the page as an example. Beyond that the general sense of this is fine – not sure we need a specific extra technique
Detlev: might get in the way if you didn't have touchscreen – don't see how this could be dealt with independently of the different type of user agent you're using
Patrick: in the example bullet point clearly saying the case of on a touch enabled kiosk or something like that. I know that was it vague enough to interpretation but I think the overall sense that instruction should be given is already in WCAG 2
Marc: in addition to the bullet update one of the existing techniques with another code example where it's kind of obvious that it's untouched voice given instructions that are in the code snippet. G131 or H44, just adding another example
Kathy: originally if it was
standard for the platform we weren't going to do that but just
if we were creating a custom gesture
... to a certain extent this is part of the assistive
technology – to a certain extent we can rely on assistive
technology to provide that information
Patrick: a shortcut way of doing something may be relevant
Kathy: I like your idea of just
adding examples in the understanding document. We can also add
one to one of the existing – I think we would want to stay away
from descriptive label ones and just add more ones on the
instructions
... it sounds like the consensus is that we don't need another
technique but we might want to just add an example of minimum
to the understanding, possibly add an example to an existing
technique
<patrick_h_lauke> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G131
Detlev: technique 131, it could be written so that using most of what the text there says already – that allows pinch zooming once it detects that the user is navigating with, which it can do on the map itself – then it can say use pinch zoom to zoom into the map – something like that
Patrick: we don't need to go into specifics, just leave it very high level, but at least it mentions the idea that sometimes it might be good to provide these instructions and hints even for things like touch
Kathy: G ones are supposed to be technology independent, H ones are HTML
Patrick: leave it high-level, just touch without saying exactly how
Kathy: any objection to modifying the first example in G131 and adding to the understanding document in 3.3.2
Marc: no objection but we aren't focusing on custom M005
RESOLUTION: have no additional techniques for 3.3.2, just add an example to the understanding documents, write the example that Patrick just did on the fly for G 131
Patrick: originated on BBC mobile
but also covered in using appropriate markup – has the effect
on mobile that in many cases and then switches to the
appropriate keyboard. I'm not sure why exactly its fallen here.
Once it switches the keyboard we need to write instructions
about this will bring up a numeric keyboard, choose it from
here. You would have to sniff exactly which browser,
which...
... platform it is. If it is that then I think we've already
made the decision that it wasn't necessary.
Kathy: next ones are 3.3.3-3.3.6
we didn't have any specific suggestions for mobile for those,
does anyone see any need to add anything for mobile
... we can skip over 3.4 because that is part of what are
doing. That brings us to principal 4, robust
... 4.1 parsing, does anyone see anything we need to do
differently for mobile and parsing
... 4.2 hamburger menu technique example – that's what M017 was
all about
Detlev: that can be far more general
Kathy: looking to see if there is already a technique on that
Patrick: 4.1.2 is more
programmatic
... having a visual representation is not 4.1.2
<patrick_h_lauke> https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
Patrick: looking for expanded in intent – don't see any sufficient techniques that cover this
Kathy: ARIA 5 – we could add an example there
<patrick_h_lauke> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/ARIA5
Patrick: simple disclosure widget doesn't have to be specific to a menu – just any kind of disclosure widget, also applies to large screen not just small screen
Kathy: thoughts about putting an example under ARIA 5
Jon: link above to something that was started but never finished by another group
Patrick: this gives a little indication and a few examples – the actual meat of the things that you should do you have to go to the ARIA documentation itself. We could add an example but it will never cover everything very completely
Kathy: or do we want to take the one that was already written and finalize it as a new one – using the wai aria expanded state to mark expandable and collapsible regions
Patrick: putting that into ARIA 5 technique seems appropriate
Jon: at the same time it's like a
catch also I don't know that people will look to that for this
particular need
... also test procedure – simpler if it split out
<jon_avila> Agreed - i vote for a separate technique
Kathy: I would vote for having
separate rather than ARIA 5 just because ARIA 5 is so
broad
... is anybody against having it separate
no objections
<scribe> ACTION: Jon to create separate disclosure widget technique for mobile [recorded in http://www.w3.org/2017/02/23-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-64 - Create separate disclosure widget technique for mobile [on Jonathan Avila - due 2017-03-02].
<Kathy> https://www.filamentgroup.com/lab/accessible-responsive.html
Detlev: change the title for the new state
Kathy: link – things you may want
to think about from responsive design
... spatial and behavioral cues, issues with different
modalities – arrow keys doesn't work with touch, for
example
Patrick: some of these are sweeping – example of Google sheets supporting mouse on android. Just going by screen size, on smaller sized viewports and don't say anything about arrow keys is probably not the right approach. Just looking at spatial and behavioral cues not using things like above left – I have a vague feeling that this is already covered in WCAG 2
Kathy: yes you can't use any sensory characteristics
Patrick: I'm not sure that this brings a lot new
Kathy: the other big comment in there was around toggles and focus order – problematic when different screen sizes. Technique around that challenge
Patrick: that would fall under
the more general do we need a technique under the focus order
and content order SC's
... I think we've touched on those
Kathy: I just wanted to make sure we had those things covered that Alistair had put out to the list
<Kathy> Accessible hiding: Where something is visually hidden but can be focused with the keyboard, I tend to fail that under 2.1 Keyboard or Focus visible depending on the content. It seems there could be another technique for this though.
Kathy: accessible hiding – technique on that
Patrick: focus isn't currently
visible because it's offscreen
... if there is a technique the covers this we could write one
in cross-reference
Kathy: I'll do research to find
if that's already covered
... there's no meeting next week, majority will be at CSUN.
I'll create a list. We have been creating actions we will go on
with those waiting for next steps with success criteria. For
the next few weeks will be working on finalizing these and
getting these submitted. We'll figure out a timeline moving
forward once we hear from the working group.
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) Found Scribe: Detlev Inferring ScribeNick: Detlev Found Scribe: Kim Inferring ScribeNick: Kim Scribes: Detlev, Kim ScribeNicks: Detlev, Kim Default Present: Detlev, patrick_h_lauke, shadi, marcjohlic, Kathy, chriscm Present: Detlev patrick_h_lauke shadi marcjohlic Kathy chriscm Kim Jon Regrets: Henny Found Date: 23 Feb 2017 Guessing minutes URL: http://www.w3.org/2017/02/23-mobile-a11y-minutes.html People with action items: jon[End of scribe.perl diagnostic output]