<trackbot> Date: 26 October 2014

<MichaelC> scribe: Joshue

<Loretta> You should have received an invitation to join in email.

<Loretta> See if this url works: https://plus.google.com/hangouts/_/google.com/wcag

<AWK> https://plus.google.com/hangouts/_/google.com/wcag

AWK: On a high level - we had the survey open for 3 weeks and we got ~ 75 people to go thru it
... It's impressive that people made their way thru it.

<agreement>

AWK: The survey wasn't as lean as we may have liked
... There is a lot of good feedback
... We can figure out now what questions and queries we can ask of it.

<AWK> Gives overview of survey format.

JOC: Very few developers in the survey - mostly a11y people

<Ryladog> Scribe: Katie Haritos-Shea

<Ryladog> ScribeNick: Ryladog

AWK: Topic: Initial review of supporting documents survey data

Initial review of supporting documents survey data

AWK: Not many people filled it out. There comments are less thorough. That was expected.
... We may need to figure out some of the ideas we gleaned from this survey, and the go for a road show, and ask folks to elaborate
... Percentage of job role we have 22 are spending 90% of their time at work. The respondents are the accessibility crowd
... Familiarity, we need some graphics to see this data.

JO: I wonder if we need to define what is an expert

MC: But that makes it difficult

Kenny Zhang joins the meeting in the room.

AWK: Kenny just finished the Chinese translation of WCAG 2

KZ: Interpretation id difficult in the translation

AWK: 23% are not really clear about the the relationship between the normative and non-normative documents are
... For the Which Sections are most helpful question....Examples were the most helpful and then Test and the description
... ....the previous were most helpful.
... That seems quite reasonable

LGR: I think the Examples are invaluable

AWK: For the Least helpful question, The results is almost the reverse except the tests.....

MC: Folks didnt like the number of links in resources...
... The people of the world are saying that the what you want us to know, is not what we, the public, want to know...

LGR: Complaints include, information is often out of date
... The people reading these documents don't want to wrestle with these issues as much as we do...

KHS: I use the layers

MC: But that may not make it easier or not. We never came - front loading important bits should be our focus - and then link off

MS: We need to do something to make it more understandable

AWK; Techniques Question: Front matter. Have you read the front matter section. The response show that Most of them havent...

<Joshue> KHS: People are really concentrating on the techs

MJ: I only recently looked at the Status of the technique - adn I find it very valuable - we should not make this go away

LGR: Those reading the techniques are not going to be interested in the front matter

JO: That is why we might want to have a role-based sets or sets
... So information optimized/based-on the role of the user (dveloper, policy maker, auditor etc)

AWK: There is a ton of info here...
... Who might enjoy doing this kind of work to extract the data from the survey....
... Excel might not be the best way to show this data.

MC: I can play with it when I get home

JO: Maybe we should sit with it and think it over. Information is beautiful is a nice resource for graphically showing this data.

LGR: But you need to analyze the data first

AWK: There are sections that some might not want o pat attention to

<Joshue> http://www.informationisbeautiful.net/books/

Jeanne Spellman arrives

MS: Folks are confused by how the docs are related
... AH says that if they have read the information they do find it useful

AWK: People was to wrk on the problem they have in front of them
... I haven't done cross correlations in the data yet

MC: There are a LOT of great suggestions

AWK: Yes, we may have kept it open too long - for the US and Australian government - and a lot - not - so, zero govies (from that group) responded (some because of Google access issues for govie employees)

MC: There are a few folks with axes to grind, not many

AWK: I haven't even had enough time to read through it all.
... Use the WORD document to see the good suggestions. Lets take 10 minutes to browse now - and highlightt what you want to talk about...

MC: Suggestion, Consider not publishing Techniques to the TR page

MJ: Is that why we always have these dated Techniques?

MC: Yes.

AWK: And we are adding more very day
... there are 30 pages of comments

MC: Use 'plain language' - which is a quote from WCAG

LGR: We need to solicit good writers
... Put the important information first

MC: It seems to me, our tendency we always say read the SC, then Understanding then Techniques. We may need to change that for developers sucgh as here is the techniques and if you want to understand more here re links to it
... Policy wonks might need the graphic first - where as developers need the technical stuff...

<Joshue> KHS: Designers and developers want to engage with different aspects of WCAG, and policy people like PMs, lawyers, legislators etc

AWK: What is a Policy Person? They ar only 1/68th of per audience - according to this survey.
... One of our challenging is that we may be trying to meet the needs of too many audiences

JO: Back in the day it needed to establish itslef as a standard - it has done that. How can it be more practical
... Streamlining

KHS: It was attempted in the past - and we could think about now - to create a Plain Language version of all three WCAG 2 main docs

MC: We should be able to archive older techniques

MS: If you are for looking for a reference which helps

JeannneS: Whitney Q say that we can change the language in a spec to make it more easily understandable. Maybe you should have a conversation with her.

AWK: An idea, how can we best move forward, do people want to take one section at a time

MC: 3 thinks give folks time to digest those sections. Or have a list discussion for a dew weeks - or let do a wiki page, and grow a resources on what WCAG should do.

LGR: Are we looking at this feedback as a re-write of these documents?

AWK: Or we could just do a reformating - it can start to address some of the issue

MS: After we have done that - we can then ask again the same questions - that will tell us if the strucrure of the existing content is the problem or is it the content

<Joshue> +q

MC: I think we can do a lot with the restructuring

MS: Presentation, simplicity of the language and the Examples

MC: The simplicity is the biggest problem
... Do a general simplification for the structure - before taking on a plain language. We also need to think about what the working group can except.

LGR: Maybe we dont quite need the same level on consensusfor simpler chnages

MC: I thinkwe could lower the bar.

LGR: I am afraid we ont get it done

JO: What do we want to do to parse this stuff. We all have our own ideas - that are mostly similar. It we systematically parsing this stuff to extract the most relevant points and take action item based on that informtion

AWK: I think we need to get more people involved in the analysis...

LGR: I am not sure why certain people are here in the Working Group, what are they looking for..

JO: We did touch on that last week.

MC: We know you want a better resources, come work with us to create it.

AWK: If we send out a couple of sections to extract the information and then share it. Should we do that?

<Joshue> +1

LGR: I am willing to do that

+1

AWK: We are just asking to identify the themes, if we get any feedback, it will be helpful.....

<scribe> ACTION: Andrew to send out assignments for identifying the themes is identified WCAG Survey questions [recorded in http://www.w3.org/2014/10/26-wai-wcag-minutes.html#action01]

<trackbot> 'Andrew' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., akirkpat2, alahart).

<scribe> ACTION: AWK to send out assignments for identifying the themes is identified WCAG Survey questions [recorded in http://www.w3.org/2014/10/26-wai-wcag-minutes.html#action02]

<trackbot> Created ACTION-290 - Send out assignments for identifying the themes is identified wcag survey questions [on Andrew Kirkpatrick - due 2014-11-02].

AWK: 15 minute break

dinner discussion

<AWK> Done.

<MichaelC> scribe: MichaelC

Review of progress of Mobile techniques

<Joshue> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Main_Page

<AWK> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

kp: We did a gap analysis against other sets of mobile guidelines

debating whether we want to create techniques for those gaps

awk: when discussing M2 (text target size)

https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M2

WG always has churn discussing techniques

khs: the TF does see that one as important enough to develop

ms: TF has list of 21 it wants to do

should it develop them? what if WG doesn´t accept them?

awk: goal is that there is guidance clarifying what developers should do

(and identify future guideline requirements)

What do people need to see to feel WCAG covers mobile?

khs: @@

js: But some of the techniques don´t apply to specific SC

how do we handle that?

lgr: They can be advisory

and put on Post WCAG 2 list

awk: Is that enough pay-off for the mobile group?

khs: not to pay attention to some specific techniques would be a mistake

awk: but what if it´s not part of WCAG?

e.g., does text target size disproportionately affect PWD?

js, khs: yes, there is research for that

khs: e.g., hand tremors, people without fingertip capacitance

lgr: conceptually that relates to keyboard accessibility

but that´s not a satisfying approach to mobile

ms: context of device doesn´t lend to keyboard use

khs: device independence concept no longer means just ¨does it work with a keyboard¨

lgr: but for this example, if it´s a device independent event but has to be triggered by touch screen, there is an issue

keyboard accessible means you could attach something if needed

awk: super-small radio buttons is something we see

is that covered by SC?

there isn´t a failure technique for making things too small

ms: differentiate between readability and interoperability

tiny radio button you can perceive but not actuate

<Joshue> MC: We are struggling around the lack of specific guidelines

<Joshue> MC: So what should we do, could we publish these techs 'guideline less' at the moment?

<Joshue> LGR: They could be advisory

<Joshue> MC: If we did that would they from a WCAG conformance view be acceptable.

<Joshue> MC: It seems to me that in addition you will need a suggestions deliverable that the techs will relate to

<Joshue> MC: We need to be careful but could have a working doc that addressed this gap

awk: there are techniques that apply at Guideline level, not SC

this example is more Principle

lgr: I bet mobile devices not keyboard accessible

ms: it´s coming

lgr: but mobile developers won´t put time into that

js: for navigation yes, but there is text input

the text input can hook to keyboard

but navigation doesn´t

lgr: because most people don´t interact that way

ms: there is no cursor

so they don´t even test that

kp: there are some with cursors

lgr: just browser

joc: can we be confident that language like ¨this must be keyboard accessible¨ will be consistent?

@@ gestural accessibility

lgr: no

ms: often people think of keyboard accessibillity as shortcuts

but that´s a different problem from what we´re exploring on mobile

lgr: gestures require lots of dexterity

kp: if gestures were consistent it would be easier

also there is no speech control on phones

these are tower of babel issues that need addressing

ms: there are no guidelines on timing

e.g., a flick, swipe, and tap differ only in speed

that´s a big a11y barrier

lgr: WCAG does have timing stuff

ms: but not really for this use case

no platform have adjustable timing yet

lgr: WCAG really fell back on keyboard access

I see that in theory that addresses mobile, but in practice not

awk: ?

ms: people using mobile devices won´t carry keyboards around

awk: will this be solved by IndieUI stuff?

lgr: maybe. Think today developers wouldn´t go to effort to support keyboard because usage would be so low

kp: keyboard fallback was always a crutch, that worked when they were endemic

but they aren´t on mobile

I´d like to see a mapping of keyboard shortcuts to functions

and map in gestures

lgr: make an interace that isn´t timing and location dependent, would meet WCAG

joc: what´s the low hanging fruit for developers?

is keyboard a11y that?

khs: @@

awk: what´s our best advice to a developer today?

<Joshue> MC: Because its the best advise or because thats what WCAG says?

khs: keyboard?

js: @@

<Joshue> +Q

khs: the events are @@

js: WCAG addresses navigation, but that doesn´t carry over well

<Joshue> -q

<Joshue> +q to say that there are some assumptions that certainly I'm making about mobile a11y that don't translate

awk: do we tell developers they can´t use keyboard access as their out because user wouldn´t be accessible?

js: users can be very successful on mobile platforms, but they´re not using keyboard access

it´s a different paradigm, and we need to be flexible to that

so I´d like to broaden definition of keyboard accessible

ms: more alternate input than keyboard a11y

kp: we don´t want to break things, esp things we don´t know about

e.g., speech input shouldn´t require me to learn a new language

I have keyboard interactions I´m used to, would like to replicate them on my mobile

khs: until we have something in place, we need to stick with what we know works

kp: in early speech days, tab was implemented as space which really broke navigation

joc: still want to look at low-hanging fruit

see a lot of work to be done in mappings

<Zakim> Joshue, you wanted to say that there are some assumptions that certainly I'm making about mobile a11y that don't translate

js: keep in mind is mobile isn´t the end point of these questions. Wearables is the next thing

khs: yes, so we really have to get away from modalities

kp: We still use QWERTY [in North America], example that some things stick around a long time

@@

<chaals> [but we don't use it in a lot of Europe, where we have AZERTY and QWERTZ and other variations by default]

ms: seems to me we should keep exploring these candidate techniques

and sort out the guideline attachments later

khs: look at which ones are highest priority first

joc: sounds like we need to decouple mobile TF from WCAG SC

khs: doing that in cognitive also

awk: maybe not decouple, just ¨not require¨

<Joshue> MC: Then lets just put out the guidance that we need to

<Joshue> MC: The Cog a11y group is doing this also

awk: there are still use cases for keyboard access

e.g., someone with tremors really needs keyboard with filterkeys

so worried about a wholesale jump away from that to new paradigm of touch

not what you´re saying, but what people may hear

one of the first challenges of the Mobile TF is to lay out what the needs are

what use cases are better on mobile, what are worse?

khs: tactile is example of something that helps everyone

js: enforcing keyboard a11y might not be the right path. Mobile platform may provide a better solution

awk: for many uers

not for all

khs: what is deaf-blind on mobile?

ms: bluetooth, refreshable braille

<Joshue> +1 to Jeanne about not missing the inherent opportunities that the mobile platform may give us

<Zakim> MichaelC, you wanted to ask about difference between mobile and small

<Joshue> MC: Is the concern of mobile a11y an issue of small devices or portable devices

mc: is concern about mobile a concern about small devices, or about portable devices?? is there a difference that needs to be captured?

khs: @@

ms: take a smart watch - is too small for speech synthesis

though may be able to provide in conjunction with a larger device it connects to

there are other examples historically of where the a11y came from partner devices

khs: for some wearables you´re attached to the device

ms: that´s model difference that may shake out

js: some provide wonderful a11y that we don´t traditionally recogniz

khs: some of the standards will be able to go beyond @@

if you can meet requirement @@

kp: is the rating of importance of techniques done by TF or WG?

mc: suggest TF, and run past WG to see where there are questions

kp: so let´s do that, and then cook up plan for where they fit

mc: suggest do technique identification, prioritization, and fleshing out

then map them to existing or ¨gap¨ success criteria

the gap SC become input to future requirements

so 2 basic deliverables there

awk: some of the shoe-horning to existing SC will have various levels of comfort

sortng that out informs future requirements

js: How do we want to present techniques?

I´ve been thinking we´d have a separate document for Mobile, like PDF and Silverlight

awk: they´re less discrete than those technologies

I imagined a collection of techniques applicable to mobile

though wonder if it´s a list of all techniques

<Joshue> MC: In the redesign discussion, we should be looking at this question as well

<Joshue> MC: Some techs shouldn't be primarily identified as only mobile - there are crossovers, not all are vertical etc

lgr: was expecting a separate document for mobile

ms: mobile web or mobile native?

there are different sets of issues there

e.g., off-screen screens, with no indication they exists

<AWK> MC: Re LGR's poiint about a mobile-specific doc. We may have that, not sure what it will or won't look like

<AWK> MC: s/poiint/point

<AWK> MC: Re mobile web or native, TF shouldn't constrain itself at the start

<AWK> MC: In terms of the deliverables we need to figure out what we will do

<AWK> MC: W3C is currently scoped for work on the web, but

<AWK> MC: this is an area of discussion with W3M

khs: e.g., touch targets is on both layers

what overlaps and what doesn´t?

many examples will merge

kp: we have a preliminary list of techniques that apply to mobile and web

there is a list of stuff that seems to be native only

mc: issue of web vs non-web content blurring is growing, we´ve got to face the question

W3C has its scope but we need to provide complete guidance for what´s in its scope

which means touching on the overlap areas

kp: screen size is a defining difference, maybe

awk: techniques

lgr: non technology specific are general techniques

khs: @@

ms: there will be devices that are solely speech controlled

mc: there were other cases like that, sometimes solved by making the new paradigm more accessible, some by accepting the old paradigm needed to be included

awk: @@

<AWK> AWK: perhaps we should make the techniques for mobile grouped by the main factors that we're using the define mobile by (for now), such as using touch screen, or pertaining to multiple and small screen sizes, etc.

<kibbitzing>

<Zakim> MichaelC, you wanted to ask about WCAG review of deliverabls

mc: how can we help the mobile TF get things reviewed and approved?

kp: we´re still learning. Specific feedback on why things come back would be really helpful.

awk: Stuff that´s come to WG for review so far has been some of the hard stuff

I try to sit in on the mobile calls to help represent WG thoughts

<various> : yes that´s helpful

kp: a third work item is the techniques that just need subtle changes

a different learning curve for that

awk: for next Techniques publication hope there will be some new mobile techniques

though there´s no requirement

we´ll publish what we have

js: for me, it´s a priority to have a batch of those

awk: it can be question of when you have enough techniques accumulated to be worth publishing the batch

and whether to hold up schedule for a batch to be complete

right now we publish more often but don´t expect a banner ¨here´s X¨

lgr: it´s clear the mobile TF has context the WG doesn´t have

and vice versa in WG considerations

should find ways to share context

kp: we had discussions of gap analysis that generated notes, would be good to share those

ms: regular check-ins help

awk: also ties to engagement question

there are people in both TF and WG activity

but at cost of each other

one issue as that a lot of the productivity swings on an individual´s engagement

kp: we welcome draft techniques from the WG too

<Loretta> http://www.calafiapaloalto.com/

<Ryladog> hi

<Ryladog> / says dinner is at 6:30 ( see URL Loretta put in above) in Palo Alto

Discussion on long-term vision for WCAG WG

<Loretta> scribe:Loretta

<Ryladog> / dinner location is for CM and JF......

Long term vision for WCAG and WCAG WG

"WAI 20/20"

(WAI 2020)

Where do we hope (or fear) we will be in 5 years.

JS: I working with UAAG and ATAG; we struggled so much with what requirement belongs wher.
... Would like to see the issues addressed in a common set of guidelines, possibly modularized for more agility.

AK: if things are sitll in modules, do they cut across WCAG/UAAG/ATAG issues?

JS: Right. If a module addressed user input, it would cover content requirements and user agent requirements together.

MS: What aboutoverlap of work?

JS: We need to keep talking with one another. Today, the groups are siloed, which produces its own duplication.
... Might also help our resources by having a single larger pool of people who could be involved in more focused, short term projects.

KHS: Also gives people better context.

Josh and Andrew and Michael are trying to figure out what is happening (if anything wiht WAI 2020)

MC: WAI 2020 grew out of initial discussions of what was called WAI 3.0 - a harmonized set of guidelines that recognizes the roles of different players.

MS: If it is published under a new name, politically does everyting need to be revisited?

MC: Yes, it would be. One of the biggest things holding us back.
... We can't say we are doing any WCAG 2.0 work. We can say we are exploring.
... As future proofed as we tried to make WCAG 2.0, we didn't really expect it to last beyond 2020.

AWK: Mike S, you talked today about simplification. today, there are guidelines for people creating content. The people creating a web page don't need to know about how to implement browsers, etc.
... Tension beteween simplifying things and pulling everything together under the same document.

KHS: Don't think that there would be one document that would cover all those aspects, but that the people working on the standards are working more closely together.

KP: What if we created some kind of mapping of the existing standards around relevant topics?

<Zakim> MichaelC, you wanted to talk about user needs

MC: When I started working at W3C, one of the big gaps was technology accessibility guidelines. I've had a deliverable for 8 years to work on that.
... : I feel the approach needed is to focus first on what users need. Then think through how to meet those needs. Sometimes there are multiple ways. Maybe the author can provide a feature. Maybe the user agent can provide a feature. Maybe both at the same time.
... e.g. enlarging text: maybe the author provides a way to enlarge text, maybe the user agent provides it.
... the technology needs to provide some mechanism.

KHS: What about the accessibility API.

MC: We will have a tree of user needs and ways they can be met, in increasing detail. At some point there willl be a thread through tthe tree that is the guidelines. Things below that level are like the techniques.

AWK: One of the areas where there has been lots of confusion. e.g. PDF accessibility, there are certain things the Reader does, and the line is different from html.
... We are seeing browsers doing less than they used to, e.g. Chrome browser with high contrast does not function the way IE does. It enables extensions so you can add lots of things, but it is not the responsibility of the Chrome developers.

MC: Another part of the picture is author needs. We tend to say the user need trumps the author need. We haven't even considered the author needs. Maybe we could find better ways to meet both.
... There is new work announced on the ePub format. They may be exploring some of that issue.

AWK: Not sure accessibility is a success on the web yet.
... When it is time to think about next generation guidelines, do we raise the bar to include more users, do we lower it so that more authors/developers will reach it, etc?
... Look at CVAA - it has been very impactful , through the threat of further impactful things. Set the bar high, and provide strong enforcement.

MS: CVAA has great teeth, but if we look at how widely supported WCAG is on the web, not very common.
... How to make this work more palatable and easier to use by more people.
... every conversation I have with someone not in this field is "this is too complicated".
... one of the goals of WCAG inthe next 5 years should be how to make this easier to adopt.

AWK: Is it really more difficult, or is it lack of interest in supporting it.

MS: Most conversations are 1) I understand the problem and why it doens't work, but 2) I don't know what to do about it , given my constraints.
... Also, lack of automated test tools.

MC: For WCAG 2 we set the requirement on ourselves that WCAG be testable. If we want a higher bar, we might need to drop that, but at the price of implementability.
... When Andrew says web accessibility isn't a great success yet, standardization and innovation are separate processes.

<Zakim> MichaelC, you wanted to talk about the requirements driving WCAG and to talk about the relationship between technology innovation and standardization

MC: We often can only influence accessibility features long after the spec for a technology is pretty much set.

MS: I worked on VoiceOVer for iOS. When it first came out, it was pretty much inaccessible. Finally got to VoiceOver in iPohne 3GS.
... what helped us: we came up with an effective gesture solution but which didn't have keyboard support. But the general guidelines of WCAG were very helpful in letting us interpret those in innovative way.
... The general characterization of accessibility in WCAG was really helpful. Keyboard accessibility was too specific.

MC: If we think of the combined accessibility requirmenets (rather than WCAG, UAAG, etc), this is even more applicable.

MS: Provide broad guidelines to people to consider, as well as specificity of possible concrete solutions.

JS: One of the things discussed in UAAG was creating personas of user needs.
... Saw a tremendous need for personas, user needs, addressing multiple disabilities (very thorny area). Would be very valuable to do that.
... I don';t know how W3C would do that, but we need it.

MC: It is hard to come up with user needs that don't touch on the web. Looking at JTC, there were a few examples, e.g. need to physically control a device.
... Have been identifying needs that I don't think are web based, but need to scrutinize carefully to be sure.
... We wouldn't discard those needs, but put them in a category that is outside our scope.

KP: Need to talk with a lot of people to put together the personas.

MS: Work has been done in universities, but not pulled together anywhere.
... Having some group to coordinate and bring clarity and logic makes a lot of sense.

JS: We need to be able to work on sexy things, to attract more people to accessibility.

MC: Also don't build theright connections to people who are working on the new technologies.
... Encourage the creation of community groups?
... Perhaps provide some structure/templates/guidance for new community groups. Later we could take their results through the process/bureacracy.

JS: There are so many people who are interesting in accessibility and want to give, but can participate in the current process.

AWK: It is interesting watching how other standards develop.
... What other standards are there that people come together to make the standard for noble reasons, rather than a business motivation for standardizing something.
... Accessibility has a little bit of business driver, but it hasn't traditionally been driven that way.
... Is the result that the level of engagement isn't as high.

Kenny: China text is different, has different screen reader, different text input mechanisms.
... Chiina standard organization wants to make standard for mobile phones.
... Also wanted a standard for Input Method Editors.
... Chinese layout is also different.
... screen reader works differently for Chinese.
... WAI discussion about next version needs to think about internationalization issues more.
... : Many challenges because text does not have word break spaces normally. This causes problems with input.
... So there are many CJK specific use cases for accessibility, as well as IME.

MX: When you translated WCAG to Chinese, did you finding missing items needed for Chinese?

Kenny: WCAG is very complex. Translation is challening, e.g., accessibility can be translated in different ways.
... Tranlsated meaning of "robust" also has a different meaning. Was translated to "compatible", which is similar but not exact.

MC: It is clear to me that we tried in WCAG to be as internationally compatible as possible, but didn't have representation from all the areas we needed. This needs to be a requirement for the next version (better representation).
... Maybe we will find requirements that are different for different regions.

KHS: We brought in one SC from JIS

MC: There is also synergy: solutions for the layout problems Kenny mentioned may solve other layout issues.

Kenny: Chinese standard trying to include accessibility IME, accessibility mobile.

KHS: Are you suggesting a separate standrd for mobile, or for WCAG to cover mobile.

Kenny: You need to define what you mean by mobile (hardware, software, application).
... China's disabled person federation wanted to define a standard for accessibility.
... All blind people use a similar touch screen mobile device.
... They use the same platform.

MC: As we set guideilnes or requirements, what do we require vs what are best practices.

JS: Hears complaints about WCAG out of date, who would have predicted the rotor on the iPhone in 2008?
... How to make the standard without squelching innovation?

<MichaelC> trackbot, end meeting

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/hink/think/
Succeeded: s/devices/devices?/
Succeeded: s/@@/we had discussions of gap analysis that generated notes, would be good to share those/
Succeeded: s/but but/but put/
Succeeded: s/The/They/
Succeeded: s/we can´t/scribe: Joshue/
Found Scribe: Joshue
Inferring ScribeNick: Joshue
Found Scribe: Katie Haritos-Shea
Found ScribeNick: Ryladog
Found Scribe: MichaelC
Inferring ScribeNick: MichaelC
Found Scribe: Loretta
Inferring ScribeNick: Loretta
Scribes: Joshue, Katie Haritos-Shea, MichaelC, Loretta
ScribeNicks: Ryladog, Joshue, MichaelC, Loretta
Present: Andrew_Kirkpatrick Michael_Cooper Mike_Shebanek Marc_Johlic Katie_Haritos-Shea Kenny_Jhong Loretta_Guarino_Reid Kim_Patch Jeanne_Spellman
Agenda: http://www.w3.org/WAI/GL/2014/10/tpac-2014
Found Date: 26 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/26-wai-wcag-minutes.html
People with action items: andrew awk

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