<scribe> scribe: jeanne

Design Process

<Sarah gives introduction to Design process>

<Ryladog> Wiki page: https://www.w3.org/WAI/GL/wiki/Main_Page/DesigningWCAG2.next

Sarah: Establish an approach that begins from an open-minded way of thinking, and move forward.

<Ryladog> David MacDonald's visualizations from the previous extension plan: http://www.davidmacd.com/blog/WCAG-extension-proposed-integration-into-WCAG.html

Sarah: start with Divergent Thinking, which is coming up with tons of ideas, then they can be evaluated.
... today's focus is on defining the problem space.
... the next session could be generating ideas
... then making choices of what solutions to pursue at the CSUN meeting and creating prototypes.

John: <reviews schedule of meetings> and present ideas to WCAG WG on April 5

Sarah: We have the opportunity to consider WCAG broadly
... we all do design all the time
... we are building an extension on WCAG, we have the opportunity to identify what we can adapt and provide additional functionality.
... we are talking about the scope
... I have nothing specific in mind. I am here to sort things out.

Katie: What we are trying to do is figure out how to put the extension work into WCAG, and now we can look at what we can do to change WCAG. If you look at what the task forces are doing, they are adding Guidelines
... I think we can modify the current work. Don't kill the existing Principles

John: We need to add Guidelines and Success Criteria
... addding guidelines is ill-defined. The task forces are working on Guidelines and success criteria
... a problem statement is interoperability
... that task forces are coming up with conflicting success criteria

Katie: We have to take that into account, we aren't going to fix that in this group.

Sarah: We have to keep it in mind.
... Can we talk about the audience for these guidelines.

John: 1. developer who is trying to incorporate new Guidelines and success criteria into their work. They want to adopt new success criteria into their work patterns.
... 2. Conformance officers who need to verify that they are in conformance
... 3. Toolmakers who make tools for conformance reporting

Katie: Would we want to change things for these audiences?

jeanne: 4. companies that make authoring tools
... 5. policymakers

<JF> 5. Policy Makers

<Ryladog> Katie: For those audiences do we want to change the existing Principles, Guidelines and SC numbering? I think not.

6. accessibility experts and people with disabilities

Alastair: 7. educators - educate people about the guidelines

John: training and educators is abolutely a category

Alastair: Accessibility consultants use it for auditing
... we let them know how their sites comply and advises them, then audits
... accessibility consultants know the guidelines the best next to the people who wrote them

Katie: Quality assurance - make sure the the product match the standards

jeanne: People with disabilities use WCAG mostly for filing complaints

<scribe> ACTION: jeanne to write up a summary of the audience discussion for the wiki [recorded in http://www.w3.org/2016/03/14-wcagnext-minutes.html#action01]

Katie: I want to focus on what we want to present in April. Redesigning the entire WCAG is beyond what I want to do right now.

John: WCAG 2.0 cannot change. Policymakers need WCAG 2.0 to stay the same. We are looking to move forward to serve the developers, accessibility experts, conformance officers, toolmakers, and ...

Sarah: I want to follow the process to identify audiences, identify constraints, @@, models.

ALastair: We know the final outcome we want -- we need to identify the middle part. We are going very wide, and I think we need to get to more details, more quickly.

John: What we have is a collection of napkin sketches on the table. What we need to do is look at what we have and identify the pros and cons, articulate the weakness and strengths.
... we need to keep in mind the users and audiences

Alastair: Can we brainstorm the problems we are facing between now and WCAG next
... conflicting success criteria
... describing to the world - complicated to WCAG + Extensions
... difficult to establish conformance

jeanne: add a problem, -- the definitions of WCAG are inadequete to modern technology -- for example, the definition of "web content" can't include hybrid mobile apps because they don't use http

John: We have to build on WCAG, we cannot fork or cause a divergence from WCAG 2.0
... if we are supporting the toolmakers, the conformance experts, the policy makers, then we can't make WCAG 2.0 obsolete.

Katie: We have to talk about adding additional extensions to WCAG. They have to take into account the success criteria that are already there

Alastair: If we can't fork or diverge from WCAG, then we may end up with accessibility requirements

Constraints

Katie: Low Vision Task Force came up with color contrast requirements that are in conflict with WCAG.
... possibly adding it as an additional requirement.
... maybe we do need to kill the existing requirement, I don't have a strong opinion.

Alastair: I think we have to say that there is another potential requirement

John: Do we make the jump from a WCAG 2.0 to a WCAG 3.0? Or do we keep extending WCAG 2.0

Katie: I think we have to do that.

John: One of the key divergences that we are looking at right now, is that an option that we rethink WCAG based on the same Principles, but renumberate or structure differently.

Katie: Let's up a table of the options
... this example of color contrast can be used to frame the options

Alastair: I see WCAG 2.1 following the principles of WCAG 2.0. When you look at rewriting WCAG, then we look at WCAG 3.0

<alastairc> Jeane: Develop a suite of standards, using principles of WCAG as the core, then suite of individual SCs & techniques that are smaller and more odular

<alastairc> Jeanne: WCAG 3 not off the table, but looking at different options.

John: The moment we start building toward a suite of requirements, it becomes more complex for the conformance officers, and educators.

Alastair: I would think that then the EU and UA policymakers would then be responsible to pick and choose and then they would make the one standard

John: This is some of our history -- the policymakers and toolmakers want to have one standard.
... let's give them one or more standards, but not building things on the fly.

Alastair: I heard a talk toward policymakers, who want one standard, and keep it updated

John: I think it is an option that we should articulate and discuss. I have already identified a "con" for it.
... we have been doing this for a while, so we don't want to get too far into these models, I think we need to look at the constraints.

Alastair: Constraints

<summarizes @@@ >

John: How do we address requirements that may conflict? The color contrast issue is the poster child for that.
... who is responsible for making those decisions
... the issue is that different task forces may come up with requirements that conflict. How do we handle it?

Sarah: I can rewrite the wiki. We can talk about what the world will look like if we are successful in achieving the project, what the world will look like if we are successful.

Alastair: We do the work, and people love it ;)

John: Time to delivery. People have already been complaining about how long it has been since they got an update.
... one the constraints that we have an a signpost of success is how to address this. How do we keep accessbility requirements up to date.

jeanne: The "suite" idea is not an audience-based model where people get to pick and choose. This is more of the CSS model - where there is a modular approach. This spec applies to Media Players, this applies to Web RTC, this applies to Hybrid apps.

John: This gets really messy really fast.

Katie: CSS doesn't get tied to civil rights legislation.

Alastair: I did a project on Mandate 376, there was a high level principles, then it broke down into technologies

Katie: There is overlap, but that is better than underlap

John: Are you thinking: If there is a touch interface, then this applies, otherwise Not Applicable

<alastairc> The high-level function requirments: http://mandate376.standards.eu/standard/functional-statements

Katie: I think we need to add additional success criteria, and say under these circumstances, this applies
... you have to write as many instances as possible. And be realistic. Not everything will apply to every interface.

Jeanne: We need a process to add to WCAG for addressing disabilities WCAG did not address

Katie: We also need a model that allows to be more nimble to address new technology and devices that are being developed
... we want to address WCAG Next with a model of being built on for the future.

Sarah: WCAG doesn't seem to be tied to specific interaction types. Preserving that would be a priority.

Katie: WCAG was written to try to make it technology neutral. But we could not anticipate all the future would bring.

<alastairc> Jeanne: Example, slide-traps in mobile. Would like to say 'navigation trap' instead of keyboard trap.

Katie: What we can do for 2.1.2 is add a new SC for "navigation trap" and then a future WCAG 3 or WCAG2020, we could delete the older outdated one.
... I think we can't kill the requirements that people depend on today in a WCAG 2.x -- we can add but we can't subtract.

Alastair: We could have so many things overriding that it becomes messy.

Katie: Example: increasing font sizes -- people say that technology took care of the 200%, so people didn't pay attention to it. Then new technology came out that didn't handle font resize well.
... I think we will see a lot of different approaches coming from the task forces.

Sarah: WHy not do the one word change in the example of keyboard -> navigation?

Katie: I don't think we have the time to do that now/

John: WCAG 2.0 is hermetically sealed. We can't change that without having the time issue of changing WCAG.
... I see two different efforts. An incremental approach that adds to what we already have and a group working on an entire rewrite

Sarah: Can anything in the WCAG 2.1 change the existing requirements.

John: I think that is a key question that should be publically addressed.

Katie: In 508, the functional requirements were not made primary. We should do functional requirements first.

Alastair: We have a conflict between timely updates and what policymakers want to stay the same.

Katie: You can't change it every 6 months, but you can do it every 2 years -- especially if you tell them that it will be updated every 2 years.
... then we have to organize the process so it can be expeditiously updated every 2 years.

John: I think that six months is too short, but 2 years seems too long.
... maybe we need a 5 year plan.

<scribe> ACTION: Katie to add the table of options to the wiki [recorded in http://www.w3.org/2016/03/14-wcagnext-minutes.html#action02]

JOhn: The long term process has been deferred for too long. I think Sarah's process needs to be considered for the longer term work.

Next meeting: Friday Boston 9am 18 March

John: Record the minutes link in the wiki and send to the WCAG mailing list.

<scribe> Chair: John

<JF> Next meeting: New Meeting Fri, Mar 18, 2016 8:00 AM - 9:30 AM Central Daylight Time https://global.gotomeeting.com/join/380705429 You can also dial in using your phone. United States : +1 (408) 650-3123 Access Code: 380-705-429

Audience

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/we can't supercede WCAG/we cannot fork or cause a divergence from WCAG 2.0/
Succeeded: s/different/differently/
Succeeded: s/interface, then this applies/interface, then this applies, otherwise Not Applicable/
Found Scribe: jeanne
Inferring ScribeNick: jeanne
Present: Katie Haritos-Shea John Sarah Alastair jeanne
Got date from IRC log name: 14 Mar 2016
Guessing minutes URL: http://www.w3.org/2016/03/14-wcagnext-minutes.html
People with action items: jeanne katie