Web Content Accessibility Guidelines Working Group Teleconference

25 Oct 2016

See also: IRC log


AWK, jon_avila, Lauriat, Rachael, Mike_Elledge, Joshue108, jeanne, marcjohlic, JF, steverep, Katie_Haritos-Shea, Makoto, Laura, Kim_D, Kathy, Avneesh, kirkwood, MichaelC, rdeltour, George, JamesNurthen, Charles_LaPierre, George_Kerscher, Romain



<AWK> akim, agenda?

<Rachael> +Rachael

<scribe> Scribe: Lauriat

<AWK> Scribe for next week?

<AWK> Mike Elledge for Nov 8

Mike: Can scribe November 8th

<AWK> rachael for Nov 1

Rachael: I can take November 1st

11:00-11:05 - Schedule for November and December

Andrew: Question I have for this is around the holiday weeks.

<AWK> anyone out Thanksgiving week?

Andrew: The Tuesday before Thanksgiving seems most likely in question. Anyone out Thanksgiving week?

Mike: I'll be out, and will scribe the 15th and not the 8th.

<Rachael> *I will be out

<laura> I will likely be out.

Lauriat: Out most of November.

<Kim_D> +Kim_D

Andrew: Not a lot of others out. How about December?

JF: The 27th and January 3rd seem a bit silly to try for.

Andrew: I'd agree, except FPWD coming up.

<AWK> December - 27th seems likely out

11:05-11:35 - Survey of GitHub items for review: https://www.w3.org/2002/09/wbs/35422/Misc20161025/

Andrew: Not hearing a whole lot, so we'll just check in occasionally.

<AWK> https://www.w3.org/2002/09/wbs/35422/Misc20161025/results

Andrew: On the survey that we had…in today's call, we'll try to bang through things before DPUB folks come at the top of the hour.

Issue 199

Andrew: So, about bookmarks in a PDF, this talks about navigating within a set of web pages, rather than within a single PDF document, so not really appropriate for this. Make it advisory? People voted to accept that response as proposed.

Katie: We should make a new technique, broad enough to cover PDFs as well.

Andrew: So you want to leave this in place until we have a new technique available?

Katie: If this is the only sufficient technique for this, then we shouldn't pull the rug out from under people, and just leave this in its place.

Andrew: We have another technique where we decided not to replace it until we had something sufficient and we still haven't done so (from months ago).

Katie: I'll volunteer to write this one.

Andrew: I don't think this comes up all that often, though?

Katie: Mistaken! Withdrawing that.

<jon_avila> accept as proposed

RESOLUTION: Accepted as proposed.

Issue 200

Andrew: On rounding and color contrast issue that we've discussed on the github issue. I've changed my opinion a bit on this: I think there is a simple resolution that this survey item links to. We've got four responses where we've had people saying we should accept as proposed.
... We've got proposals to add zeros to make it clearer that it means without rounding.
... I've put an example here: if you come up with 2.999 and you should have 3.001, you can't notice the difference. But we needed to have a clearly understood rule. Talked with Adobe about this and they could only think of examples in terms of equal or greater than.

JF: Just adding an additional zero…I know we didn't want to make it harder to read, but I don't think I see adding two zeros to make it clear that it means the hundredths place.

Wilco: I just wanted to add an example: we found one with aXe Core where we had a contrast ration three digits out, and aXe reported a violation, because it didn't meet 4.50 as the contrast ratio. In tools, we do round up, since you want to do some sort of rounding. I agree we don't want a whole lot of discussion on this.

(Caller): You could just round down and not have to worry about that, right?

<Joshue108> +1

<jon_avila> I would round down 4.499 would not be compliant IMO

<Zakim> just, you wanted to say I agree with accepting this...

JF: That sounds testable statement and definitive statement to round down.

Katie: I agree with this.

<AWK> ack +

<Zakim> +1, you wanted to rounding down

Steve: Speaking as an engineer: I agree with what you said, Andrew, that the math matters. You need to make a decision on how to round or leave it up to the tool. I'd say the latter. If you want to round to eight or three significant digits, that'd fine. No other real way to interpret greater than or equal to.

<Joshue108> ack +1

Josh: +1, I like the idea of the rounding down thing. I hope we revisit this anyway in our future work.

Andrew: Does what we have in the understanding document clarify? Is the problem Wilco brought up still be a problem given that?

JF: The problem we'll have will come from a legal compliance issue. Will someone notice the difference at that small of a threshold?

Wilco: I think the clarification helps a lot.

Andrew: Sounds like all okay with this? Any objections as proposed?

<AWK> "The 7:1 and 4.5:1 contrast ratios referenced in this Success Criteria are intended to be treated as threshold values. When comparing the computed contrast ratio to the Success Criteria ratio the computed values should not be rounded but instead the comparison should performed using standard rules for significant figures."

Jon: Would you mind clarifying the specifics?


<MoeKraft> The 4.5:1 and 3:1 contrast ratios referenced in this Success Criteria are intended to be treated as threshold values. When comparing the computed contrast ratio to the Success Criteria ratio the computed values should not be rounded but instead the comparison should performed using standard rules for significant figures.

Andrew: [reads pasted bits]

Jon: For the 4.489, that would not be compliant?

Andrew: Correct.

Mike: To the point just made: if after you say, afterward, maybe "eg. 4.499 would not be compliant"

<Kim_D> +1 to adding clarifiying example.

<Ryladog> +1 to Mike

Steve: I just think you need to omit the sentence "standard rules for significant figures" - that doesn't mean anything even as an engineer.

<Joshue108> +1 to steve

Mike: +1 to examples.

<laura> +1 to adding an example.

<Ryladog> +1 to adding clarifiying example also

Steve: If you say 4.50 and then say its an absolute line, it contradicts (at least confuses) itself.

Josh: Is this a little oranges and apples? Talking floats vs. standard integers and not comparing like and like?

Andrew: I agree we can just get rid of that latter part, that's not a problem.

<JF> Isn't that why we would want to add a zero

<Mike_Elledge> +1

Andrew: Any other comments if we add that example?

<jon_avila> that should make it clear

Katie: Works for me.

<AWK> proposal is to remove sig fig part of sentence and add Mike's example.

JF: Can we see the whole thing as proposed?

<AWK> The 7:1 and 4.5:1 contrast ratios referenced in this Success Criteria are intended to be treated as threshold values. When comparing the computed contrast ratio to the Success Criteria ratio the computed values should not be rounded (eg. 4.499:1 would not meet the 4.5:1 threshold).

Andrew: Pasted into IRC

<JF> +1

Andrew: Any objections?

<Kathy> +1

RESOLUTION: Accepted as amended.

<MoeKraft> +1

<laura> +1

<Makoto> +1

<Mike_Elledge> +1

Andrew: We've three left on the survey, maybe have time for one more?

ISSUE: 245

<trackbot> Created ISSUE-46 - 245. Please complete additional details at <http://www.w3.org/WAI/GL/track/issues/46/edit>.

<AWK> TOPIC Issue 232

Issue 232

Andrew: Michael points out this has two issues: a bad link and a suggestion for another link. James made the point that we shouldn't add links to anything on blogs, since unstable.
... If a bad link on the webpage, we should clearly remove it. Should we replace it?
... …and now, of course, the link resolves.

JF: Why do we link to things outside of our control?

Andrew: We do all over the place. No endorsement implied, etc. all noted.

JF: Note a gap in internal documentation?

Andrew: We could tell them.

Katie: Good idea. Then we can point to our tutorials.

JF: Pointing to a useful resource, but the fact that we don't have something internal seems to me that we have a gap. We can point to EO and highlight it.

Michael: Point of information: as far as broken links go, we always have to fix broken links when updating documentation, which I do simply by removing them. Not unusual to simply remove links that go stale, so we shouldn't get too wound up about this one in the context of a public comment. We have I think at least a thousand external links and should just deal with the issue of broken links in the simplest way possible.

Andrew: So for this link, do we want to replace it?

<MoeKraft> +1

<Rachael> +1

<Ryladog> +1

<laura> +1

Andrew: Respond back "We've fixed the broken link and electing not to add an additional link at this time."

<Wilco> +1

Michael: Did we fix it, or did it just go unbroken?

<Ryladog> +1

Andrew: I see something in the chain where I said I fixed it.

RESOLUTION: Accept proposal to decline adding the link.

11:05-11:35 - Survey of GitHub items for review: https://www.w3.org/2002/09/wbs/35422/Misc20161025/

Mike: Helpful to say no longer broken?

Andrew: Already in there, so all good.

11:35-12:00 - Silver Plan Survey: https://www.w3.org/2002/09/wbs/35422/SilverProcess/

<Mike_Elledge> +1

Andrew: On to the Silver item. We've got some comments, four looks great (no changes) and three looks great (changes needed).

Michael: Pretty big scope, so we need to recognize that and that things should change. [ed: +1] Not sure what needs to go into the plan around that, but we need to document that the plan may change as things go through the process. We may need to add in more language around minimizing craziness. Then: Checkpoints for the WG.

<jeanne> Silver SubGroup did add WCAG WG Checkpoints, if you refresh the page.

Michael: We'll need several points through the process where the group reports back to the WG on progress made at various places throughout, not sure exactly where. Last: We should go through the TF creation process for this.

Andrew: Laura, you had a similar comment around where the WG is involved.

Laura: Yeah, basically the same as Michael's comment on that.

Andrew: The research and initial drafting I expect would take place in the TF, but at some point, likely when 2.1 it done, then there is no longer two big projects and only have one big project, we'd likely have greater merging around the efforts at that time.
... Jeanne had comments along the same lines on adjusting to make changes as needed and check-in points.

<jeanne> https://www.w3.org/WAI/GL/wiki/Process_of_Designing_Silver

<Zakim> jeanne, you wanted to say that the WCAG WG Checkpoints have been added to the process

Jeanne: Just wanted to say that we did update the document in our meeting this morning, and saw the comments. We've updated the process to include a rough timeline with that and various checkpoints added to cover that.

Michael: I feel like a few of the earlier checkpoints will basically just send a report, not necessarily with a sign-off needed, but I'm inclined to think that we should have a sign-off on all points.

Jeanne: Can you say more specifically what the sign-off would cover?

<Ryladog> +1 to MC comments for WG approvals

Michael: Maybe something as simple as "We think that the research looks like it covers what it needs to" or could request going back to cover some identified gap or something.
... Of course, the more you interface with the WG, the less likely that'll happen.

<jon_avila> Agreed

JF: "…likely when 2.1 is done…" - that assumes that 2.1 includes all of the SC that we have and leave no work remaining to do.

Andrew: Not specifying exactly what will happen in the group, and that we can't adjust what will happen in the group with respect to the process for Silver. This process (Phase 1, Phase2, etc.), it gets to somewhere around Phase 3 where we'll have 2.1 out the door. It could turn out that at that point, we have to look at things that would go into a 2.2 and a rechartering process that says we'll look at 2.2 and Silver and each of these at some timeline.
... Valid question, I don't think that this process for Silver affects 2.2. Does my clarify things?

JF: More: is that the consensus of the group? Do we share this understanding?

Andrew: I'd be surprised if our collective understanding matched that, but I don't think that affects the process of Silver. Definitely an important question, but not one that affects this outcome.
... Any other comments on this…or concerns (etc.)?
... Next steps for this, a call for consensus to the larger WG for what we have as the process. Not carved into granite, but guidance for what will ultimately become the TF. We've had a small subgroup for designing the process, but that will expand, as many/some of you will join.
... So next, we'll work on the work statement to spin up the TF.

JamesN: What skillsets and backgrounds will you need for this work?

<AWK> s/(phone, missed name, sorry)/James

Jeanne: For this very first phase, we'll most need people with research skills. People who are used to writing statistically valid surveys, give interviews, know how to analyze research data and come up with valid results.
... As we move out of that, we'll look for people with specific topic expertise, but that first part will take around a year.
... Anyone with contacts (particularly grad students) working in related fields, and…[now I've forgotten what you said]

<Joshue108_> SL: Jeanne and I have started to look at the outline of methods

<Joshue108_> SL: That we would look at for each phase

<Joshue108_> SL: We are identifying resources etc that we need

<Joshue108_> SL: We have documented this in the wiki.

Michael: Planning on running the work statement through the WG in the future, correct?

Andrew: Yep.

Laura: What kind of a time commitment is involved? I remember hearing eight hours per week, but is that required? Could people join with fewer than 4 hours per week? For instance 4 hours per week?

Jeanne: Currently based on what we do. Happy to talk with you more about this, but just based on the requirements for what we do today.

Laura: Figuring out a way for people to contribute in smaller ways would help.

Michael: I know that the TF needs to remain a fairly strong and forward-moving group, but we may have other opportunities to help out with things.

Mike: Jeanne, can you give a little more detail on the types of research topics, how those capabilities would be used?

<jeanne> https://www.w3.org/WAI/GL/wiki/Process_of_Designing_Silver

Jeanne: Sure! If you take a look at the process, in the Discovery phase, we have user research, and…well…research. The user research will include surveys, diary studies, interviews, etc. The "research" section will have analysis, more traditional research methods, adaptations of WCAG and how those are being used.

Mike: DIdn't know if you meant around process, or something more specific to cognitive issues, etc.

Jeanne: Right - not getting into what goes into Silver, yet. More research around what how WCAG is used, etc.

<AWK> Lauriat: two points:

<Joshue108_> SL: Firstly, a point was made about contributions

<Joshue108_> SL: We will be working with others

<AWK> ... the contributions of people. lots of points where people who aren't in the TF will be able to contribute

<Joshue108_> SL: there will be lots to do and we will be looking for volunteers/me I got it

<Joshue108_> SL: The research will look at how things are done, and look for adaptations etc

<Joshue108_> SL: So I've looked at somethings and identified gaps - and the research will cover the information architecture of WCAG.

Andrew: I think we've cleared the queue. Any objections to accepting this process and we'll do the CFC after that?

JF: Survey open until 31st?

Andrew: Yep.

RESOLUTION: Accepted process document with revisions.

12:00-12:30 - DPUB joining WCAG to discuss techniques and success criteria (please review http://w3c.github.io/dpub-accessibility/)

Andrew: We've got [several folks] who've joined in, not sure if others will join? Talking about techniques and potential SC. Welcome!

Avneesh: Talking the specification that we've written about documents, based on WCAG. Main objective of today's call: to get a good idea of the timeline, the breadth of the techniques and SC that we can target for WCAG 2.1. If we've time left, we have some specific questions.

<Joshue108_> https://www.w3.org/WAI/GL/wiki/Timelines

Andrew: There's two different timelines we're talking about: techniques (non-normative) every six months, and we have an internal timeline where we need content submitted and approved to meet the given dates. Generally, we target a release just before CSUN and another six months later. Generally: due in end of May (for that given release), resolve comments, publish.
... The way we've been doing this for the techniques and understanding documents, being tight on the timeline in principle, but if not much going in a given bit and the group has time to process maybe a week after the deadline, that can be okay. Ah: mid-November due for the CSUN one, finalized by mid-December.
... For 2.1, we ask the TFs to have SC in by December 1. From there, we'll produce (the WG will work on ) a FPWD in early February, pending the membership accepting the charter so that we can publish that.
... We can point you to the github materials with the format of that.

Avneesh: December 1 for finalized or for the first draft of SC?

Andrew: We'll have discussion overlapping with things, so we'll be consolidating things with all of the people in the TFs (part of WCAG).

Avneesh: Is that the only window of time, up to December 1, or will we have another window of time?

Andrew: Came up before on this call, actually. Yes, but not determined for a timeline, whether for a 2.2 or Silver. We've determined the process for Silver, but as a major release that allows us to do more to bring in other topic areas (such as user agents).
... Somewhere in the last six months of our charter, we'll make a firm decision (maybe before then) as to whether we'll make a 2.2 or whether we've made enough progress to just go to the next big thing.

<clapierre> no

Avneesh: Okay about a timeline, then. Any questions from others around that?

<JF> s/(Caller9)/Avneesh/

<AWK> Success criteria proposals go here: https://github.com/w3c/wcag21/issues

<AWK> (issue 1 is an example)

George: What we'd like to talk about with SC for web publication (a fairly broad term): with EPUB especially which includes offline, we'd like to focus on the online, web publication made up of a collection of online documents, with SC around those web publications.
... First SC idea relates to proper reading order for the whole document - Chapter 2 comes after Chapter 1, you can move through the document. Another SC: you can navigate documents through their structure (so: level 1 heading followed by level 2, etc.), relating to the relative ease of navigating through the document.
... Relating to schema.org…with EPUB 3, identifying metadata relating to the web publication as a whole to allow people to determine whether this publication is something they could use successfully.

<Ryladog> +1 to using schema.org or other metadata

George: That textual content could be converted to audio via TTS, to Braille, and support the visual presentation. If the whole document could be consumed in that way, we'd know that it's accessible.
... Web publications, having a whole document with logical reading order, and having metadata relating to the publication. We didn't want to overload at the beginning, but start with fundaments to the group.

<Joshue108_> Those suggestions don't seem different from 2.4.3 and 3.2.3?

<Joshue108_> The first 2 anyway...

Andrew: I think the metadata one is definitely the most different. The first two, I wonder whether WCAG doesn't already cover these. In an EPUB document, whether that counts as a web page or multiple web pages. If you have an EPUB doc on the web, do you access this through one URI for the entire package, or separate URIs for each part within the package?

(Caller10): You've got a single identifier for the entire package, and then many different URIs (resources, manifest, navigation, spine (list of HTML files referenced), all linked within the package). On the web, how that'll work is still under development. Today, we have websites that've created their own mechanism for rendering publications (some work well, others not so well), but having a logical reading order is essential.

Charles: Considering the whole thing as a package that's accessible from the web is one of those gaps. We just want to see if we can create some SC here to help define what is useful.

<AWK> http://w3c.github.io/dpub-accessibility/

Andrew: Are you talking about…[adding a link]

<Zakim> JF, you wanted to seek clarity on "document" versus "document collection"

JF: Wanted to ask about differences between a document and a document collection. We talked earlier on the call about bookmarks in a PDF file, so there's a technique here. Is there a different between a singular document or a document collection, as there may be different requirements for these, depending.

<Joshue108_> Good question John

<clapierre> Yes that is the Accessibility Note Andrew.

(Caller10): When Daisy consortium looked at a (for example) 900-page document counting as a single document, which crashed everything. So having multiple components making up a single publication, everyone agrees that we have to go that way. But it ultimately makes up a single publication. In the context of an LMS, when a professor wants to give students access to a collection of documents that ultimately make up one paper. We see this in the WHO compre[CUT]

scribe: documents all on one thing, like Zika virus, which all make up one whole.

Katie: When we look at web pages today, they're a collection of pages all relating to something. The standard speaks to metadata around this. This fits very nicely, we just need to figure out how to do it.

<Wilco> +1 to what katie said

(Caller10): The work we've done, we've done closely with IMS [I think, please correct].

Katie: Perfect.

<AWK> web page: a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

Andrew: Many of our criteria reference "web page" - [defines from glossary]

<clapierre> Here is the Schema.org proposal for AccessModeSufficient http://pending.webschemas.org/accessModeSufficient

<Joshue108_> what's our definition of embedded?

Andrew: EPUB on the web is on the edge of that, depending on the implementation. But it sounds like an EPUB on the web accessed via a single URI would constitute a single web page. We need to clarify this for those referencing this, though. Is this new SC or new techniques? How can we, in the future, avoid this kind of confusion by acknowledging content presented in different forms.

Josh: What's our definition of embedded, then? Is, with EPUB, each piece within the wrapper an embedded piece of content?

George: Many of the problems we've had relate to the zip container. We believe that it should be identical or round-trip-able (online/offline). A new standard for publications, maybe EPUB 4, not yet chartered, but we already see content published on the web that would benefit from WCAG guidance.

Katie: EPUB format grew out of DAISY and such, mostly made up of W3C specs (HTML, etc.) so it fits very nicely with the other work we're doing.

George: Possibility of IDPF and W3C combining, currently underway, not a certainty, but discussions in progress.

Andrew: George et al, have we given you what you need, or do we have another next step we should cover?

Avneesh: If this is a serious proposition for the December timeline or do we need more discussion on this?

Katie: I think we need more discussion on this.

Andrew: Yeah, maybe start a conversation on the mailing list.

Wilco: Close tie in to other work happening in here.

Josh: Further talk needed, yeah.

<Mike_Elledge> bye!

<Joshue108_> yeah close that

<Joshue108_> thanks

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Accepted as proposed.
  2. Accepted as amended.
  3. Accept proposal to decline adding the link.
  4. Accepted process document with revisions.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/10/25 16:36:14 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Succeeded: s/a[pp/app/
Succeeded: s/(phone, missed name, sorry)/JamesN/
FAILED: s/(phone, missed name, sorry)/James/
Succeeded: s/Could I join with four hours per week?/Could people join with fewer than 4 hours per week? For instance 4 hours per week?/
Succeeded: s/(caller)/Avneesh/
Succeeded: s/(Caller9)/Avneesh/
Succeeded: s/(Caller9)/Avneesh/
Succeeded: s/(Caller9)/Avneesh/
FAILED: s/(Caller9)/Avneesh/
Succeeded: s/Georges/George/
Succeeded: s/Chapter 2 comes after Chapter 1/First SC idea relates to proper reading order for the whole document - Chapter 2 comes after Chapter 1/
Succeeded: s/(Caller10)/George/
Succeeded: s/(Caller10)/George/
Found Scribe: Lauriat
Inferring ScribeNick: Lauriat
Default Present: AWK, jon_avila, Lauriat, Rachael, Mike_Elledge, Joshue108, jeanne, marcjohlic, JF, steverep, Katie_Haritos-Shea, Makoto, Laura, Kim_D, Kathy, Avneesh, kirkwood, MichaelC, rdeltour, George, JamesNurthen, Charles_LaPierre, George_Kerscher, Romain
Present: AWK jon_avila Lauriat Rachael Mike_Elledge Joshue108 jeanne marcjohlic JF steverep Katie_Haritos-Shea Makoto Laura Kim_D Kathy Avneesh kirkwood MichaelC rdeltour George JamesNurthen Charles_LaPierre George_Kerscher Romain
Found Date: 25 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/25-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]