Web Content Accessibility Guidelines Working Group Teleconference -- 07 Apr 2015

<trackbot> Date: 07 April 2015

<Joshue> https://www.w3.org/WAI/GL/wiki/Scribe_List

<inserted> Scribe: Loretta

TPAC

JOC: Any change in status since last week?

AWK: There is interest and concern about making the group more inclusive of international audiences.

<Joshue> https://www.w3.org/2002/09/wbs/35422/24thMarch2015/results#x2673

AWK: Maybe we say "probably not", but keep an eye on it.
... Maybe hold a meeting there as an engagement/get started event.

<Joshue> 3 people will be there.

<Joshue> have confirmed

AWK: If we move to a more asynchronous meeting model, any decisions made there would be ratified on the list anyway.

KHS: Makoto Ueki wants to rejoin the working group, and he felt there would be great interest and attendance for a meeting in Japan because of the new laws going into effect in Japan based on WCAG2.
... If there is a way to advertise to that audience, we might attract more attendance.

MC: Between 8 - 15 would be the preferred meeting size.
... I can only go if my groups are meeting. I may not be able to go, given the current status. They are very strict about room reservations, so we need to either commit to a meeting or not.

TPAC final call

Extension model discussion: Including the sub topics

JOC: The extension model road map is open ended, and different groups apply it in different ways, depending on what they need.

<Joshue> http://www.w3.org/html/wg/wiki/ExtensionHowTo

JOC: SHould we talk about how html5 uses the extension model?
... LInk to general model of extension specifications.

MC: In W3C process, there isn't a universal process for what an extension is. SOme groups have adopted a modular approach, where final spec is the union of all their modules.
... Other groups didnt start with modular approach, but need came up for extensions.
... HMTL5 model: there is hmtl5, and then anyone can write an extension. If you want it to be part of html5, you are responsible for 1) writing a good spec, 2) (xx), 3) doing the implementation testing.
... If you pass all those bars, they will include the extension in the next version of html5 automatically.
... It is also possible that extensions aren't made part of the html5 core, but is seen to have value for parts of the html5 community. The HTML5 WG says such extensions are also legitimate.
... We were looking at the latter for a WCAG model; extensions would not change the definition of WCAG2. Extensions would need to meet the same quality bar. If you wanted to conform to WCAG + extension, you can do so. However, it is still possible to conform just to WCAG 2.
... Open question: if a policy adopts both WCAG2 and an extension, is it possible for the extension to change WCAG2 itself?

KW: Clarification request: if we look at hmtl5 and html5 extensions, is ARIA considered an extension?

JOC: ARIA is a separate spec in its own right.

<Zakim> MichaelC, you wanted to mention delta specifications

<Joshue> s/ARIA is a separate extension/ARIA is a separate specification

MC: ARIA is not an hmtl5 extension. ARIA 1.0 is incorporated into hmtl5, via a long and difficult negotiation. So to an extent it worked like an extension, but it was incorporated before we completed the testing bar.
... I forgot to mention: W3C has the concept of Delta Specification. I don't know exactly what it is.
... If we publish a spec that changes any aspect of WCAG2, I think that makes it a Delta Specification, which adds a new level of scrutiny to the process.

KHS: ARIA works with html4 and scripting as well as html5; it is technology-agnostic.

MC: Yes, although an html4 validation won't accept it.

Background pointers

What type of extensions?

JOC: Current potential extensions: mobile, cognitive, low vision.
... What would such specs be like?
... Want to keep techniques themselves off the rec track, so we can update them.
... Should extension specs be structured like WCAG (success criteria with non-normative techniques) or in some other way?
... WHat happens when we find gaps in what WCAG covers? DOes the extension come up with new success criteria, and conformance requirements?

ME: Is there any harm in structuring things like WCAG2? I like the idea of consistency.

JOC: I want to keep things as light as possible, and not bloating the canon.

MC: Possible harm: if the structure of WCAG2 prevents us from doing something we want to accomplish in an extension spec.
... I'm not sure this is a real risk, but something to consider.

<AWK> Is wearables part of mobile?

KHS: additional potential extensions: wearable, automotive.
... I don't think wearables are part of mobile because it is a different paradigm.
... May be accessing health info, info about your body, etc.
... May want to wait for these extensions until the technology itself is more mature.

KW: I think there is a lot that may be common or sharable between the different extensions. We should think about how the extensions will interact with one another, too. Maybe it is ok to have duplication between extensions

<Ryladog> Or touch on an automtive UI or screen

KW: When considering mobile, we realized that much of what was covered also applies to touch-screen based devices like laptops.

JOC: Core parts of these extensions may reach across multiple domains.

Will extensions be A, AA, AAA?

AWK: this is a hard question to answer in the abstract.

<Joshue> https://www.w3.org/WAI/GL/wiki/Post_WCAG_2

AWK: we have the post-wcag2 wiki. We need to look at those items to inform our decisions, as well as the work of the mobile and cognitive task forces.

<AWK> https://www.w3.org/WAI/GL/wiki/Post_WCAG_2

AWK: who wants to help sort through that information?

KHS: I would like to see most items fall at levels A and AA, since most laws only take those levels.

MC: If we want extensions to support conformance, A and AA seem to make most sense.

<Ryladog> +1

MC: HOwever, a concept of best practices may be important, which may or may not reach the same level of requirements as success criteria.
... SOme AAA success criteria are there because they don't apply to all web sites. If we limited the scope of content addressed by extensions, may not need AAA.

AWK: THe group should review the criteria for A, AA and AAA in the past, and whether to continue with that criteria.
... However, we don't want to debate the merit of items just based on popular vote. We should have objective criteria for appropriate levels for any extension.
... Otherwise, it will limit our ability to deliver the extension itself.

JOC: I feel that these discussions will occur. The debate about AAA success criteria being ignored will affect the extension specs. WOuld AAA in extensions be ignored even more?

ME: Do we already have something defined as best practices? If not, is it wise to introduce yet another layer of advice. As an implementor, I would think success criteria themselves would meet this need, and if there were a separate category of best practices, I would find it confusing.

Will extensions conform to WCAG requirements for success criteria?

<Ryladog> Maybe, but I am assuming the extensions themselves will in fact have their own SC - that are a required adjunct to WCAG2 if/when adopted. In other words WCAG 2 is the baseline.

KHS: My initial assumption is that the extensions themselves would have their own success criteria, but would be combined with the WCAG2 success criteria (that is, both sets must be met).

<Mike_Elledge> +1

JOC: I hope extensions would conform to the core WCAG success criteria as much as is possible.

<Joshue> LGR: Can the extensions override the WCAG SCs?

<Joshue> JOC: Yes, will the extension overide WCAG SC?

<Ryladog> I think this particular discussion can be worked on best at a F2F where many memebers will be able to attend

KHS: This reminds me of the original discussions about levels and priorities, and is best determined in face to face meetings (with critical mass of attendance). It is a very complicated thing that people need to agree to.

AWK: We do a lot of work not in the same room, and that will probably continue.

KHS: Still think this kind of discussion of complicated issues works best in person.

<Ryladog> Just because it hard doesnt mean that we should attempt it

Categorisation of current open issues in the context of the extension model

<Ryladog> What quickly comes to mind is enhancement of visual focus being improved, as well as text and content resize - both under the Low Vision Extension.

AWK: Looking for volunteers to do some categorization of current open issues. If we ask everyone to do it, no one does it.

JOC: I should ping LIsa to ask the cognitive group to look at current issues; likewise Kathy and mobile group.

<AWK> https://www.w3.org/WAI/GL/wiki/Post_WCAG_2

AWK: Items here may fall into more than one extension category.
... This has been a place to put things that we couldnt change. Now that we are looking at the possibility of change through extensions, we should look at this items more carefully.

JOC: Post WCAG 2 page vs Open Issues page?

MJ: I see an Open Topics page, but no Open Issues page.

WCAG working group and public engagement/interaction

JOC: How do we make public interaction with the WG easier? An example is moving to the use of github.
... How do we facilitate public engagement? How do we get people interested in the work of the group.

<Ryladog> Suggest JAPANESE outreach

MC: How can we get useful technique submissions from outside the working group?
... technique submission form is usually submitted blank. Even when people try to fill it out, they often don't think about the issues of publishing techniques the same way we do, so we don't use their work, which is discouraging.

<inserted> Scribe: AWK

<Joshue> MC: That ties into the goal for reformatting the source format etc

MC: need to connect techniques and GL's together better

<Joshue> MC: We can tie the guidelines together in theory and then output them in different ways.

MC: need an easier format to encourage greater participation external to the group
... GitHub may offer possibilities but can also be frustrating for newbies
... W3C Web annotations may hold some promise also, but new still
... if Web annotations are enabled in the doc people can comment and the annotation is stored on one or more annotation server and people can view that
... mine for edits

JOC: like RE-spec?

MC: Not exactly, that's more behind the scenes

KHS: my suggestion was about Japanese outreach as a way to get more people involved.

JOC: we should do as Michael suggested, which is to look at how the WHAT WG spec commenting is done.
... might make the process easier and lower the bar for participation
... OK, I think we are done for today!

Trackbot, end meeting

<Mike_Elledge> bye!

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

07 Apr 2015

Attendees

Contents