See also: IRC log
<Joshue108> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List
<AWK> trackbot, start meeting
<trackbot> Meeting: Web Content Accessibility Guidelines Working Group Teleconference
<trackbot> Date: 16 August 2016
<AWK> +AWK
<Joshue108> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List
<KimD> + KimD
TPAC registration closes soon, please register soon!
Flights needed as well, please check those asap.
<Joshue108> proposed changes to the H86 technique.
<Joshue108> https://github.com/w3c/wcag/issues/216.
Consensus was to accept as proposed.
Comment from Rachael: "original writings" seems unclear, several alternatives are suggested in the comment.
<AWK> "Leetspeak uses various combinations of characters, including numerals and special characters, to replace standard characters."
AWK could use "standard characters".
<AWK> originally said this in technique: Leetspeak uses various combinations of ASCII characters to replace Latinate letters
AWK: phrase came from the original comment. suggest "standard characters" instead.
Joashue108: Any objections? (None heard)
AWK: point is that it is not latin-only, which is more obvious to commenter from Japan.
RESOLUTION: The phrase standard characters will be used instead
<Joshue108> https://github.com/w3c/wcag/pull/218/files?diff=split
AWK: Comment from Michael about making this change across techniques. However, it's not the highest priority item right now. This one is straightforward.
Joshue108: If anyone would like to go through all the other techniques, please let us know.
RESOLUTION: Accepted update to H86 as proposed
AWK: Comments from Duff Johnson,
e.g. updating the version of PDFUA. https://github.com/w3c/wcag/issues/220
... A comment about removing a UA (VoiceOver) is reasonable,
but not the same criteria that we have used in general.
... This is also an area that we can update quite easily, we
can make that change any time.
Joshue108: Hopefully Duff will be happy with the changes, and can provide more input on the Ua issue.
RESOLUTION: Agreed to the response, and notes can be updated easily.
<Joshue108> https://github.com/w3c/wcag/pull/217/files?diff=split
<Joshue108> https://github.com/w3c/wcag/issues/209
Joshue108: Relates to no-embed,
not used much any more as it has been superseded but other
technologies.
... Michael made a good comment/catch that we don't simply use
HTML definition as the basis for inclusion.
<Joshue108> AC: From a dev perspective, if no-one is using it why do we need to support it?
<Joshue108> AC: I don't see any reason to stilll include.
Joshue108: Does anyone know of use-cases where embed is used?
JamesN: I'm sure there is one,
but don't know off the top of my head.
... Getting rid of the technique doesn't disqualify it, so I
don't mind removing it so long as we don't put in a failure
technique of the reverse.
AWK: Looking at the technique, all you have to do is have a no-embed element following an embed element. There is no test for the fall back equivalent. Not a good test procedure, as it doesn't check the alt is appropriate.
Katy: Sufficient for media techniques? Then I agree, however, I'm a bit more conservative about keeping techniques in.
<JF> +1 to Katie
Joshue108: We have been in places like this before, but we might not get around to improving it, we're aware it needs fixing but it might not happen.
AWK: Not sure it is worth fixing as people aren't using it, so let's not waste time on the wording.
JamesN: Isn't there a step we can grab from another technique?
AWK: we could do that, and send for review, and then people wonder why we are doing that?
JF: This is a small thing, so leave it as is, look forward not back.
<Joshue_10> +1
<laura> +1
DavidM: Would remove it.
Joshue108: Need to move on, either remove it or keep as-is.
AWK: Need to respond to the comment.
Katie: For legacy content, we need to keep as-is.
Joshue108: Ok, it isn't breaking anything, let's keep as-is.
JF: Response to the comment?
Joshue108: Consensus is to keep due to legacy concerns.
<AWK> Proposed response: Thank you for the comment. While this is not a technique that represents the most current practice, the group is keeping this technique active in support of legacy content.
<laura> +1
<Rachael> +1
<Joshue_10> +1
<JF> +1 to that response
<Joshue_10> +1 from James
<Joshue_10> +1 from KHS
<Makoto> +1
<jeanne> 1
<marcjohlic> +1
<Greg_Lowney> +1
<Kathy> +1
<kirkwood> +1
<jeanne> +1
<Mike_Elledge> +1
<Joshue_10> +1 from GregL
RESOLUTION: H46 - response accepted as proposed
<Joshue_10> (http://www.w3.org/2016/08/draft-wcag-charter
Joshue108: We have a new draft charter.
Mike: What does @@ACT deliverable mean?
Joshue: It's a placeholder, and we have a new TF for standardise testing rules, including automation.
Mike: Regarding the communication (under 5), and say "technical discussions are conducted in public", but then the meetings are not open to public participation, can we clarify?
AWK: Its boilerplate in that area, the discussions are conducted in public, i.e. meeting minutes, list, and github are all public. However, that doesn't mean you can join the call.
Josh: Agree we should qualify that statement.
AWK: It does say that further down.
Mike: It is the "discussion" bit that is confusing.
AWK: So say "available for public review"? (Yes)
Josh: Technical discussions are public, the discussions are archived...
DavidM: Trying to get across it is not hidden, and open to other people's opinions.
<laura> typo: “The mission of the Accessibility Guidelines Working Group Charter” should be “The mission of the Accessibility Guidelines Working Group”
<Rachael> typo:
<Rachael> "implementations of each of feature defined in the specification" should be "implementations of each feature defined in the specification.."
Josh: Note that the 2.1 work and 3.0 are outlined in the charter. Any comments/questions please let us know.
JamesN: Is there a version with the differences from the previous?
AWK: It is a new document in a
new format, so unfortunately not. Some of the things that are
changed:
... Added dot releases starting with 2.1.
... Removed is extensions.
... Should read it as allowing to do a 2.2, and 1st working
draft for Silver. Not expected the ability to do 2.1, 2.2. and
silver in one go.
<JF> Huge +1 to leaving open the possibility of WCAG 2.2 (or even, god-forbid, a WCAG 2.3...)
AWK: We should publish 2.1, and
then realise there is a bunch of things that are at least 5
years away, and then feel like there is nothing we can do.
That's why it is open to a 2.2
... If this starts in Sept, 3 years on, if we publish 2.1 in
March 2018, it might be tight to do a 2.2
Josh: Focus is on 2.1, possible to do other iterations, and 3.0 / Silver. Any other comments?
JF: Under 2.3 timeline, does that
mean we do editorial changes, or new requirements?
... We have March 2017 for understanding and techniques. Are
they for existing docs, or for the new ones? (2.1)
AWK: Intent was for 2.0, not 2.1.
We will need to mark things as applicable to 2.0, not
2.1.
... Previous discussion was that techniques would be added to
the aggregate grouping.
JF: There maybe some techniques
that aren't applicable with 2.0, but don't have a mandate for
backwards compatibility?
... Are the techniques/understanding evergreen?
AWK: There is some content that
will only apply to 2.1, but everything from 2.0 should be
applicable.
... Should maintain backwards compatibility, also we have some
things to discuss with W3C & EO group.
Josh: Timeline is a little confusing, agree with AWK but need to separate out the timeline a bit. The 2.0 will be updated as needed, but perhaps the current work should only be called out in the charter for 2.1 updates? Can say that 2.0 will be updated as required, but the timeline focuses on 2.1
<Mike_Elledge> +1 to focus timeline on 2.1
Greg: The doc seems a little
confusing about the working group name, uses old and new. The
abbreviations are in the old name. E.g. in out of scope it is
the WCAG WG, also in the deliverables.
... There's a non-working link, could do with a placeholder (or
fix) for that.
AWK: thank you
Greg: was a little worried about a need for updates to ATAG/UAAG under this charter?
Josh: we aren't responsible for ATAG/UAAG
Greg: true, but as part of silver?
Josh: Hasn't been decided how that will look yet.
AWK: we are unlikely to be publishing an ATAG 2.1 (for example). But we could provide merged recommendations in our deliverables aimed at user agents / content tools, later.
Greg: at the moment, members of ATAG/UAAG merged in, and if Silver takes on those aspects, the people in WCAG / AGWAG(?) would work on it. I'd like to acknowledge that it is within the province of this WG, although understand that could be problematic to include.
Josh: It is a little chicken and egg with regards to chartering, but the nuts and bolts are still to be resolved, some of which are not in our control (e.g. funding).
JF: as an observer, if this group isn't responsible for ATAG/UAAG, who is? Those notes seem to be the responsibility of this WG?
<AWK> Only UAAG is a note. ATAG is a REC
Josh: In terms of the work progressing, not sure how it will work.
JF: Useful to note that these
notes/recommendations are published, we retain ownership of
them.
... +1 to brining in EO to the understanding, not sure about
the techniques, have some concerns there.
Josh: It would be great for EO to help with some of these docs, and the understanding docs especially would benefit.
Jeanne: I think UA & authoring have been included, for Greg's concerns, perhaps a bullet under the deliverables - any necessary updates to UAAG / ATAG as the need arises (but these are not expected)
<JF> +1 to what Jeanne is saying - that is/was what I was attempting to say as well
AWK: What sort of updates to ATAG / UAAG are you thinking of here? We could maintain the errata, but trying not to commit to things we can't do.
Jeanne: Would be good to have the placeholder in case we do want to update something.
Greg: If something came up, there is an owner here. For the errata, the groups were responsive for non-normative docs as well. They could be updated fairly easily.
Josh: There is a good point about us not putting things into the Charter that become problematic in future. Need to be cautious. Whilst there is an ownership issue and errata for ATAG/UAAG, putting it in the charter does put it on us. On a practical level that might make sense for Silver, but still difficult.
<Zakim> Ryladog, you wanted to not talk because I cant but to say that what Jeanne just said, IoT will have browser impacts that we need to think about in the future
Katie: Not sure if it needs to be in the charter, but browsers & authoring tools for IOT (Internet of things) need to know about these guidelines.
<Zakim> JF, you wanted to say taht Josh is doing a great job of explaining why we *shouldn't* lose ownership of UAAG and ATAG
<jeanne> Propose bullet for 2.2 Other Deliverables: * Working Group Notes to support understanding, interpretation, or errata of ATAG 2.0 and UAAG 2.0 as need arise (It is not anticipated that the need will arise).
JF: Appreciate we don't want to commit to things we can't deliver, but any errata to UAAG/ATAG should be with us. This working group retains control over them, rather than them being in limbo.
Josh: Will put on agenda for co-ordination call.
JameN: do we need things in the charter for non-normative things?
AWK: No, deliverables for non-normative things can be done without being in the charter.
<Ryladog> IT is not that just that IOT (Internet of things) need to know about these guidelines - but that they may need to be updated to address IoT/WoT content, browsers and author tools for that content
JamesN: Errata appears to be non-normative according to the charter?
AWK: WCAG2 errata is
non-normative, not in TR space at the moment.
... WCAG2 errate is non-normative.
DavidM: Would the browser makers have any objection to us taking over that work?
<jeanne> But WCAG did assume members and expertise of ATAG and UAAG.
AWK: There would be some concerns if we took on things we don't have the background on, but there is some expectation that UAAG/ATAG should be covered as the WGs were combined.
<Ryladog> and Jim Allen
AWK: primary driver in context of TFs was for 2.1, but people from ATAG/UAAG would be more relevant to Silver.
<Ryladog> It is sliver
JF: In either scenario, the current charter should mention ATAG/UAAG.
Josh: those updates should be done in a more iterative manner.
JF: Could create TFs when needed if issues arise.
Greg: UAAG/ATAG expertise not as impactful?
AWK: in 2.1, not silver.
<Greg_Lowney> UA and AT expertise might not be as "impactful" in this WG as WC expertise, but I don’t not want our charter to prohibit us from using that expertise if work on those areas are needed before Silver.
Greg: I'm afraid that our charter
would prohibit us from using that expertise if we needed to
make updates to ATAG/UAAG.
... The fact non-normative docs can be updated easily just
leaves ATAG as the possibly orphaned one.
<Greg_Lowney> The phrase "Other non-normative documents may be created such as:" should be "updated or created" to allow updating "Implementing ATAG 2.0" or UAAG 2.0.
<Joshue_10> +1
Greg: at the moment it says only create new ones.
AWK: Ok.
AWK: Interested in people's opinion on the WG name? Accessibility Guidelines WG?
Greg: I'm for AGWAG!
<Mike_Elledge> +1
<Rachael> +1 to changing name
<JF> +1 to AgWag
AWK: AG-WG (AG WUG)
<Ryladog> I would prefer we not change until Silver is our priority
I don't mind, in general people associate with the guidelines, not the working group, doesn't bother me...
DavidM: Why not be the WAI WG
then? Oh, yea, they have protocols etc.
... WCAG has a brand name there.
AWK: this decision is about the
WG, not the guidelines name.
... The naming could help with showing people we've broadened
scope.
Josh: That could help.
<JF> WTAG? Web Technologies Accessibility Guideline?
AWK: Please think about it...
JF: WTAG, web technology accessibility guidelines?
<Mike_Elledge> Online Accessibility Guidelines WG?
<jeanne> I like the Accessibility Guidelines WG, because it includes native mobile.
AWK: There is an WTAG doc worked on in APA...
<Mike_Elledge> Bye all!
<kirkwood> I'd not change the acronym. It's a known entity.
<laura> bye
trackbot, end meeting
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/The 2.0 will be updated as needed, but perhaps the current work should be for 2.1 updates?/The 2.0 will be updated as needed, but perhaps the current work should only be called out in the charter for 2.1 updates?/ Succeeded: s/not in CR/not in TR/ Succeeded: s/WCAG2 is non-normative/WCAG2 errata is non-normative/ No ScribeNick specified. Guessing ScribeNick: alastairc Inferring Scribes: alastairc Default Present: Kathy, AWK, Joshue, David, Makoto, AlastairC, jeanne, Mike_Elledge, SarahHorton, JF, Rachael, KimD, marcjohlic, kirkwood, Laura, katie, GregL, JamesNurthen Present: Kathy AWK Joshue David Makoto AlastairC jeanne Mike_Elledge SarahHorton JF Rachael KimD marcjohlic kirkwood Laura katie GregL JamesNurthen Found Date: 16 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/16-wai-wcag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]