Accessibility Guidelines Working Group Teleconference

01 Feb 2018


AWK, JF, Brooks, alastairc, Glenda, KimD, SteveRepsher, Pietro, jamesn, jasonjgw, Greg_Lowney
Bruce_Bailey, Laura_Carlson, Makoto_Ueki, Detlev, Marc_Johlic


<LisaSeemanKestenbaum> i just called in but no one is there

<LisaSeemanKestenbaum> i think i got the time wrong

<scribe> scribe: JF

Publishing COGA Gap Analysis Note

<AWK> https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/

AWK: We have a COGA Gap Analysis doc that is being worked on at the URL noted

both the COGA TF and AG WG need to approve this note so that we can advance it

proposal is that we grant "standing permission" to the TF to publish rolling edits to that doc

not a final approval, but procedurally, it makes it easier for rolling edits

AWK: concerns, thoughts, questions?

DMD: will this be the document that is being proposed in the draft INtroduction language?

AWK: no, this is (will be) a Working Draft

WCAG 2.1 can't point to WD's

AWK: so the request now is for permission to publish working drafts as required, toward a goal of Full On [sic] NOTE

there will be a final check-in before it moves forward formally

<alastairc> Seems reasonable to have that published. Would definately want to be reminded for a review before a final publication.

MC: some may not be familair with the standing consent process, it just makes things easier for rapid iteration of the WD

AWK: anyone opposed, or have concerns?

+1 to standing consent

<alastairc> Broader point: Where should feedback go?

DMD: concernd about section regarding user-safety

MC: comment on the drat, or the proposed process?

DMD: the draft

AC: where should comments go?

LS: there is a section where comments can be left

<AWK> https://github.com/w3c/coga/issues/new

<alastairc> Ah, here: https://github.com/w3c/coga/issues

MC: the draft also explains how to comment, and where

<LisaSeemanKestenbaum> +1

AWK: any objection to sending a CfC for the Standing Permission?

<Glenda> No objection. +1


<alastairc> +1

JN: seeking clarification. If things don't go as planned, we can have another CfC to address concerns

AWK: yes, if the WG feels things aren't right, and raise those issues but the TF doesn't address those concerns, than the WG can still react

JN: not anticipating thta, but want to be sure that we can make those kinds of aadjustments

GitHub comment auto-response

<AWK> https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/1086.html

<AWK> https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/1084.html

AWK: discussion last Tuesday about a common "starting response"

this is to address the concern about discussion on GitHub - setting appropriate expectations if the commenter is following GitHyb

also explains how to unsubscribe to the thread (shut up GitHub)

although if you are mentioned, or then comment further, you are automatically re-subscribed (which is a good thing)

<LisaSeemanKestenbaum> I need to go for a but. will try and come back soon

also a process statement about replies to our replies

JN: agree with general idea. Would like to see it edited down to something briefer

suggesting a bulleted list with URLs with more details

<Zakim> MichaelC, you wanted to ask about heavy commenters

MC: was going to suggest same thing

<KimD> +1 to short bulleted list

AWK: any other comments?

JN: confirms JF's understanding, that there would be a collection of "More details" links

AWK: so it could be one link with different named anchors on the document?

JN: essentially yes

AWK: so breaking it down, with individual links to each item that would be addressed

+1 to that AWK

AWK: will work on that some, and then put into action for when comments start rolling in. Currently noe received, but expect that to change

Update on Abstract language

AWK: there has been active discussion since Tuesday around Intro language for 2.1

the abstract is a brief version to represent the content of the document as a whole

so anything we add also needs to be represented inthe larger document somewhere

feels like we're getting close, and there is forward movement

<david-macdonald> Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of implementation recommendations serving a diverse range of people with disabilities. Following these guidelines will make Web content more accessible and provide improved access to an increasingly larger group of people using the web independently. Disabilities include impairments related to blindness and low vision, deafness and hearing loss, limited movement, photosensiti[CUT]

AWK: have been asking, while we think about this, to focus on the overall objective here

<AWK> Overal objectives:

<AWK> WCAG 2.1 includes recommendations for _improving_ access to web content for a variety of types of disabilities (includes vision, hearing, coga, etc)

<AWK> WCAG 2.1 does not eliminate all possible gaps in accessibility for any users with disabilities, even at AAA.

<AWK> The currently identified gaps are a particular problem for users with cognitive, language and learning disabilities because of immature assistive technologies, as well as implementation, testability, and internationalization considerations.

<AWK> Additional resources are available for authors who want to address accessibility more comprehensively.

AWK: seeking agreement on the key four bullets

<david-macdonald> Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of implementation recommendations serving a diverse range of people with disabilities. Following these guidelines will make Web content more accessible and provide improved access to an increasingly larger group of people using the web independently.

<david-macdonald> Disabilities include impairments related to blindness and low vision, deafness and hearing loss, limited movement, photosensitivity, cognitive, language and learning disabilities, and combinations of these. The guidelines also makes Web content more usable for ageing related impairment, short or long-term changing abilities, usage in different circumstances and devices, and often improve usability in general.

<david-macdonald> Although these guidelines cover many important issues, they do not claim to address the needs of people with all types, degrees, and combinations of disabilities. Identified gaps currently affecting users with cognitive, language and learning disabilities are frequently due to the variability of needs within this population, the lack technologies that can universally meet ​their needs, and ​the challenge of ​creating formal requirements [CUT]

<david-macdonald> implementable​ and applicable internationally. We encourage authors to consider our supplemental guidance on improving the user experience for people with learning and cognitive disabilities, as well as other disabilities, found at: w3.org/wiki/XXX Work will continue in this area as technologies mature in the marketplace.

AWK: asking group to review current draft language

MC: when we discussed editing the abstract, the expectation was for modest tweaks. The abstract is generally written by "team"
... In particular this document is supposed to be a high-level over-view, and concerned that this is over-reaching
... we should be very careful, and think deeply, about edits to this document
... language appears to criticize the Rec, which isn't good

<MichaelC> https://www.w3.org/WAI/intro/wcag

suggest that the links to resources be part of the Intro, and not the abstract

<AWK> JF: asking Michael if the work looks more like the intro than abstract?

<AWK> MC: Yes, it seems to look like the intro content

<AWK> ... still room for some edits of abstract

<AWK> ... expected more modest changes

MC: believe what we are looking at is more appropriate as Intro. We need to be sure we aren't over-claiming

<AWK> ... the team did write the abstract originally

MC: "team" means W3C staf

DMD: when doing a side-by-side, not seeing a lot of difference.
... appreciate not criticizing ourselves

MC: haven't done a line-by-line, and cannot do so at this moment
... was expecting a les expansive re-write

AWK: we need to have a better, more formal look and discussion, and compare against Abstract and Intro of 2.0 v. 2.1

<alastairc> Looks like good content, worth discussing exactly where it goes.

AWK: seeking to take the temperature however - anything inaccurate or causes issues?

JW: generally support M. Cooper, and would prefer that we not be critical of the guidelines
... some appropriate statement about limitations is reasonable

AWK: work proceeds then. Good chance to get some quick thoughts, will revisit this soon

open issues

<AWK> https://github.com/w3c/wcag21/issues

AWK: we have a few open issues

comments 747, 746, related to 134, as well as others - but it's the top four on the URL posted

would be good if we can address sooner rather than later

if anyone wants to take one or more and draft responses, that would be helpful

AWK also 733... making it the top 5

AWK: ideally would like to do a survey to approve draft responses

Techniques in GitHub repo (Michael)

<AWK> https://github.com/w3c/wcag21/tree/Techniques

MC: propose how to deal with Techniques in the repro

some time ago added some structure to address this, but did it as a branch

review of that URL has different Technologies as well as a template

there are a number of class attributes that should be used to support current publishing mechanisms

<AWK> https://github.com/w3c/wcag21/tree/Techniques#editing-techniques

MC: look at the ReadMe, about mid-document is a section on "How To Edit"
... Propose to use the process outlined there
... propose a unique if brief file name
... using the class attributes will make automation down the road much simpler
... propose creating branches for Techniques - one Technique per branch - and then we can review and merge as required

AWK: also to note that for those who have issues with GitHub, free to do the work elsewhere early on. However at some point it will need to be brought into GitHub. Plenty of assistance avialble ther

ask Chairs or other WG member if/when you need GitHub help

MC: if you are comfortable with editing HTML, but not GitHub, go ahead and make the HTML edits and then bring forward
... please however do not make changes to the structure, as it might introduce issues down the road (and the Technique might be rejected because of that)

AWK: does this sound reasonable, logical, do-able?
... any oppostion?
... question about live exmaples

MC: " haven't sorted that out yet. have a few ideas on different ways to do it

one might be to have a folder under Techniques (under the high-level Technique)

So Techniques that have live examples should have a common folder name (TBD)

MC: open to input on what would work best
... if ther are no opinions, MC will make the proposal

JN: Previously, our examples were 'snippets' of code and not a full page.

will the template be a sample page taht we insert the examples into?

<AWK> Example of an example: https://www.w3.org/WAI/WCAG20/Techniques/working-examples/ARIA1/describedby-close.html

MC: we may. Believes there is a difference between inline examples versus working examples
... so the workng example - linked from the Technique - would be fully working example

if there is a request/demand for a template page, we can visit that idea

JN: did something very similar in the ARIA Practices WG

MC: aware of that, will have more discussions there

AWK: can look at those examples. Thinking bundling all examples under one dirctory may still make sense
... will continue to investigate. If you are eager to get start, proceed with caution. Will send out an email when the 'system' is ready
... linking to live examples needs to happen soon

MC: can merge the Techniques folder into Master

SR: would think that the live example should reside with the Technique, not external to
... also, live examples may be optional - not all SC require them

MC: in WCAG 2.0, we did not include TEchniques in line because of concerns around usability and comprehension

Think the current "See the example" in the current Techniques is weak - should look to improve that

but continue to link to examples

JN: want to look at "ownership" issues related to code. I.e. if you submit code, it becomes a community thing, open for wide review and edits

want to avoid 'author statements' in the examples - it's group code, not individual code

JN: hoping to ensure we are clear about this up-front

AWK: sounds like this is a good approach.

will adivse when it's ready to roll


trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/02/01 18:02:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/agneda+ open issues//
Succeeded: s/questons/questions/
Succeeded: s/+!/+1/
Succeeded: s/Update on Abstract language/GitHub comment auto-response/
Succeeded: s/yues/yes/
Succeeded: s/inaccurat/inaccurate/
Succeeded: s/ak/ask/
Succeeded: s/"See and example:/"See the example"/
Succeeded: s/clar/clear/
Default Present: AWK, JF, Brooks, alastairc, Glenda, KimD, SteveRepsher, Pietro, jamesn, jasonjgw, Greg_Lowney
Present: AWK JF Brooks alastairc Glenda KimD SteveRepsher Pietro jamesn jasonjgw Greg_Lowney
Regrets: Bruce_Bailey Laura_Carlson Makoto_Ueki Detlev Marc_Johlic
Found Scribe: JF
Inferring ScribeNick: JF
Found Date: 01 Feb 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]