Re: Agenda Thursday AG WG call - 12:00pm

Colleagues, minutes for the call can be found at:, or below as text:

- DRAFT - Accessibility Guidelines Working Group Teleconference 01 Feb 2018
Present AWK, JF, Brooks, alastairc, Glenda, KimD, SteveRepsher, Pietro,
jamesn, jasonjgw, Greg_Lowney Regrets Bruce_Bailey, Laura_Carlson,
Makoto_Ueki, Detlev, Marc_Johlic Chair AWK Scribe JF

   - Topics <>
      1. Publishing COGA Gap Analysis Note
      2. GitHub comment auto-response
      3. Update on Abstract language
      4. open issues <>
      5. Techniques in GitHub repo (Michael)
   - Summary of Action Items
   - Summary of Resolutions


<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: We have a COGA Gap Analysis doc that is being worked on at the URL

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

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


<alastairc> Ah, here:

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: 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

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

+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

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: 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
... language appears to criticize the Rec, which isn't good


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

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

<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: 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

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)


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


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
... 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

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

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:

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]

On Thu, Feb 1, 2018 at 10:48 AM, Marc Johlic <> wrote:

> Regrets - team meetings in Austin this week.
> -Marc Johlic
> On Wed, Jan 31, 2018 at 6:33 PM, Andrew Kirkpatrick <>
> wrote:
>> The AGWG WG will be meeting on Thursday, 11 January 2018 at 12.00 PM
>> Eastern US (Length: up to 1 hour).
>> To confirm, this call starts at noon Boston time and runs for 1 hour.
>> Please reply with regrets to the list.
>> Scribe list:
>> <>
>> IRC:<
>> <>
>>  <>
>> <>>
>>  port: 6665 channel #ag
>> Agenda
>>    1. Closing Issues
>>    2. Update on abstract language
>>    3. Understanding content
>> To connect to the meeting:
>> Meeting call-in and web-ex information is at this non-public page:
>> Thanks,
>> AWK
>> Andrew Kirkpatrick
>> Group Product Manager, Accessibility
>> Adobe
>> <>

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.

Advancing the mission of digital accessibility and inclusion

Received on Thursday, 1 February 2018 18:09:26 UTC