Web Content Accessibility Guidelines Working Group Teleconference

17 Jun 2014


See also: IRC log


+1.617.766.aaaa, AWK, David_MacDonald, Sailesh_Panchang, Marc_Johlic, Michael_Cooper, Lisa_Seeman, +31.30.239.aabb, Wilco, Joshue, Katie_Haritos-Shea, +1.571.389.aacc, jon_avila, James_Nurthen
Kathleen_Anderson, Barry_Johnson, Kathy_Wahlbin


<trackbot> Date: 17 June 2014

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

<Joshue> Chair: AWK

<scribe> scribe: marcjohlic

Upcoming calls. No call July 1.

Cognitive Task Force Report https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#Reports

AWK: Most of US are typically out for July 4th week - no call scheduled for July 1
... Update on Cognitive Task Force by Lisa Seeman

LS: Moving along - slow progress but there is progress

<AWK> June Cognitive TF report: https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Reports#June_2014_-_Task_Force_Report

LS: 2 Important issues:
... 1) Trying to make a schedule for when we meet w/ WCAG WG - felt the most effective way would be to divide into chunks. This will give us useful deadlines
... Want to divide gap analysis - divide into 2 chunks (possibly 3)
... First chunk is a background review of disabilities and challenges they face with different ICTs
... Aim is to have first chunk ready for informal review (possibly just by chairs)

<Joshue> +q

LS: 6 weeks later to have more of an internal review by WCAG WG and PF

JOC: Did you pick user group types - or divide them - what was the methodology?

LS: Wanted to make them as diverse as possible - but also expertise and passion inside of the group
... Sorted by severity
... Diverse in functionality
... Brain function
... We've hit on the large groups - learning disabilities, dementia
... 2) Main work at the moment is to work on the gap analysis.. but also working on 1) Description of the different brain functions
... and 2) We're working on a page of "techniques".
... The idea is we don't want to lose ideas that come up in the discussions. So we want a place where folks can jot things down as they come up with them.
... Big discussion on what that document should look like.
... Open to feedback from WCAG WG on the structure of this page

<Lisa_Seeman> http://accessibility.athena-ict.com/TechniquesCOGA.html

LS: Again main point is so that we don't lose ideas right now as these things are being discussed.
... Not a TF review document at this point

AWK: Will probably want to look at existing techniques at some point to see where these cognitive techniques can fit in

LS: So first chunk is looking at the different user groups (dyslexia etc) - and describing them and their challenges in using ICT. Part of the gap analysis.. stage 1

JOC: Any sense of a time frame on gap analysis?

LS: Hoping to send first chunk in about 6 weeks to 2 months - just for you to review. Full review for working group in about 3 months
... And another 3 months for the next chunk
... So altogether in 6 months a complete gap analysis
... Everything is on our wiki - so always feel free to have a look to see the current state

JOC: We'll touch base about the gap analysis toward the end of July and see where we're at - hopefully something for working group to review early august.

June 10 Survey: https://www.w3.org/2002/09/wbs/35422/10thJune2014/

AWK: Anyone else getting 408 errors when going to W3C wiki / comment pages

Wilco: Also getting them

AWK: Have to reload pages several times

MC: Will forward on to System's teams to look into 408 errors / issues

1. Pull request #27 Proposed edit for ACTION-1378

RESOLUTION: Accept the pull request as proposed and edit the pull request per Josh's response.

2. Pull request #28 ACTION-184 Example of validating multiple controls

<Joshue> MarcJ: I'd just like to see something better.

<Joshue> AWK: Are you happy with an everything is good message?

<Joshue> MJ: Yup

AWK: I may have changed the example when I pulled it into GitHub
... Will take a look at fixing the example so that it does not give a 404 error when fields are correct.

MC: Original example (above) seems to be working

<Joshue> +q

RESOLUTION: Accept pull request 28

3. New technique: Creating a conforming alternate version for web pages which are designed to be responsive / progressively enhanced

JOC: Still wasn't clear - some concerns about the framing of it.

AWK: Larger point of this technique is that if you're publishing web pages to a large variety of device types - specifically making different versions for ipods, minis, android, desktop - so that you have a lot of action going on. The suggestion is people may not have resources to test all of the versions.
... Suggestion is that you want to ensure you're doing everything you can making all of your versions accessible, the way to reach conformance is by saying: "This is the version we are fully accessible with - and it can be reached by all other versions".
... Concerns are that the other version may get left behind

JOC: As an overall approach I would like description tidied up - like the edits that AWK has made.
... Example 1 seemed to be a toggle version using javascript - was that the intent?

AWK: Yes, that is correct - that is how Example 1 is working. Instead of just taking you to a different version, it is using a script to strip away the enhancements to bring you back to the simpler, pre-enhanced version

DM: Few thoughts

<jamesn_> i'll try number 3

<Joshue> +q

DM: We usually separate out progressive enhancement from responsive design

AWK: Talking about progressive enhancement and responsive design as being non-intersecting.

<Joshue> +q

AWK: My reading on this one is that it is using progressive enhancement to id the target browser and making some enhancements to the base html to arrive at a responsive design for that target

JOC: I see a lot of responsive design (as david pointed out) being at the CSS layer and not scripting
... Don't see them as mutually exclusive - may be not real deficit in having them together, but had initial concern with them being conflated - but may be unfounded?

<jon_avila> According to wikipedia page they are related concepts.http://en.wikipedia.org/wiki/Responsive_web_design

<Joshue> thanks jon

Sailesh: Agree with David

<Wilco> +1

Sailesh: They are two different concepts - so maybe there should be 2 separate techniques

<jamesn_> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/C29

JN: We already have a CSS technique for this - C29

<Joshue> http://www.w3.org/TR/WCAG-TECHS/C29.html

<AWK> http://www.w3.org/TR/WCAG20-TECHS/C29.html

JN: Using a style switcher for conforming version

DM: It's not quite the same

<Joshue> +q

Sailesh: If we could pull progressive enhancement language into C29
... Why does this technique talk about both PE and RD?

DM: I think it's a lot of CSS - most of it is CSS changing. May use scripting to control it, but it's CSS

JA: I sent a link from wikipedia - the concepts aren't the same but related
... I think they're related but i understand how they could be confusing to the reader. I don't have a strong opinion on this.

JN: Could we just remove "responsive" from the title?

JOC: Feel it could firm this technique up if it didn't mention "responsive". My hunch is that it should be left out.

Sailesh: Would argue to keep responsive and get rid of "progressive enhancement"

JOC: Progressive enhancement (PE) has been around, whereas Responsive Design (RD) is relatively new.

AWK: So the answer is to remove PE or RD? Just don't have them both in the same technique because they are different?

JA: Based on reading the proposed technique it talks about the pre-enhanced technique. Would be better for PE. I would say we have a separate technique for RD. You have to make the same decisions for RD - "which version do you test".

<Joshue> +1 to Jon

JA: Goes back to the same conformance claims

DM: At some point I do want to create a technique in meeting zoom requirements with RD
... Maybe in RD technique we talk about this

<Joshue> +q

AWK: I'm not sure how this technique would be taken apart - it all seems intertwined.

JOC: Differing opinions on what RD actually is
... Sounds like we're all coming at this from different angles
... In terms of progressing with this - I'd like to do whatever will create the least confusion

Sailesh: Primary focus should be RD - but how you attain it - via CSS, or PE can be different

AWK: Feel we're getting hung up on a few words here

JOC: We should get Alistair in on a call as part of this discussion

JA: Test procedure would have to change too if we remove PE

<Joshue> +1 to changing pre-enhanced conforming alt vers language

<jamesn_> I can't support having a link to http://www.w3.org/TR/mobile-bp/ in this description at all

<Joshue> +q

RESOLUTION: Leave open - Josh will contact Alistair to see if we can discuss next week on the call

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-06-17 16:31:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/overall would/overall approach I would/
Succeeded: s/having htem/having them/
Found Scribe: marcjohlic
Inferring ScribeNick: marcjohlic
Default Present: +1.617.766.aaaa, AWK, David_MacDonald, Sailesh_Panchang, Marc_Johlic, Michael_Cooper, Lisa_Seeman, +31.30.239.aabb, Wilco, Joshue, Katie_Haritos-Shea, +1.571.389.aacc, jon_avila, James_Nurthen
Present: +1.617.766.aaaa AWK David_MacDonald Sailesh_Panchang Marc_Johlic Michael_Cooper Lisa_Seeman +31.30.239.aabb Wilco Joshue Katie_Haritos-Shea +1.571.389.aacc jon_avila James_Nurthen
Regrets: Kathleen_Anderson Barry_Johnson Kathy_Wahlbin
Agenda: http://lists.w3.org/Archives/Public/w3c-wai-gl/2014AprJun/0227.html
Found Date: 17 Jun 2014
Guessing minutes URL: http://www.w3.org/2014/06/17-wai-wcag-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]