<LisaSeemanKestenbaum> i just called in but no one is there
<LisaSeemanKestenbaum> i think i got the time wrong
<scribe> scribe: JF
<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
+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
<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
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
<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
<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
+1
trackbot, end meeting
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]