W3C

- DRAFT -

Education and Outreach Working Group Face-to-Face

27-29 Oct 2014

Agenda

Topics and material

Attendees

Present
Jon, Wayne, Vivienne, Sharron, Shawn, Shadi, Kevin, Eric (Tue), Anna Belle (Mon remote)
Observers
@@ (Mon morning), Andrew Kirkpatrick (Tue morning), Nobuo Saito (Tue morning), Reinaldo Ferraz (Tue afternoon), Evangelos
Chair
Shawn
Scribe
Sharron, EricE, Kevin

Contents

See also Topics and material.



Monday

Overview

<shawn> http://www.w3.org/WAI/DEV/deliverables

<shawn> WAi position on accessibility & inclusive design http://www.w3.org/WAI/users/Overview.html

<shawn> W4A paper: The role of accessibility in a universal web. (available from MIT Open Access Articles http://dspace.mit.edu/handle/1721.1/88013) - ask Shawn for paper in a different format

<shawn> Media Accessibility User Requirements http://www.w3.org/WAI/PF/media-a11y-reqs/#accessible-media-requirements-by-type-of-disability

<shawn> EO doc http://www.w3.org/WAI/intro/people-use-web/diversity

Media Accessibility User Requirements

Questions

Do we want to recommend that the Media Accessibility User Requirements document more closely aligns with the EO document How People with Disabilities Use the Web?

kevin: Should Media Accessibility User Requirements not simply refer to the How People with Disabilities Use the Web?

shawn: That is one possibility

<shawn> How PWDS is vetted through EOWG

Wayne: Media Accessibility User Requirements does have something more about media

Jon: Tone of voice slightly differs between the two documents

shawn: Concern that just linking to the How People with Disabilities Use the Web would direct people away

Jon: May end up adding too many specific examples into the main EO document

<kevin_> Wayne: Would be good if someone could have a general read and review

Summary: Aim to review the Media Accessibility User Requirements and comparison with How PWDs --- MAUR focus on issues that are related to use of media. This document should include a link back to the How People with Disabilities Use the Web. The EO document should ideally include a link back to the Media requirements as a related resource.

<shawn> Do want to add anything to How PWDs on media?

<shawn> Probably: MAUR would have some info (for people who won't follow links) and to keep it tightly focused on media. then link to How PWDs.

<shawn> maybeMAUR will suggest improvement to How PWDS, e.g., atypical color perceptions rather than color blindness

s/maybeMAUR/Maybe MAUR

/me woops

s| /me woops||

<shawn7> 1. anything in MAUR that we want to add to HowP ?

<shawn7> 2. What to have in MAUR - probably limited intro and focus only on media specific.

<shawn7> 3. Would links to HowP be in each specific section or only overall at top?

Joint meeting with WCAG WG

@@WCAG minutes

<shawn> ACTION: Shawn and all change WCAG Overview to WCAG 2.0 Overview [recorded in http://www.w3.org/2014/10/27-eo-irc]

<trackbot> Created ACTION-302 - And all change wcag overview to wcag 2.0 overview [on Shawn Henry - due 2014-11-03].

Quickref rejig

<shawn> https://www.w3.org/WAI/GL/wiki/Resource_Redesign/Quickref/Analysis

<shawn> 1. quick start - just start here

<shawn> 2. quick ref - filters on wcag

<shawn> &/or search on wcag

<vivienne> http://www.accessiq.org/web-accessibility-wizard

<shawn> intro stuff e.g., accessibility principles in HowPWDs Use Web

shadi: Three functions/audience:
... Someone new to accessibility and wants to learn more
... This is the progressive disclosure idea

<shawn> at a glance - accessibility principles - 10 tips

shadi: Next is the 'caniuse' type function

<shawn> http://www.w3.org/2009/cheatsheet/

shadi: Much more task based and includes everything associated with a topic
... Last item is 'I am evaluating/developing to AA using HTML and CSS'. 'Give me a customised checklist'

shawn: More of a checklist... such as the WCAG-EM Report Tool list

wayne: Use case -
... This data structure violates WCAG identified in audit.
... Experienced developer but not accessibility savvy
... How do they incorporate accessibility into their framework
... How do they find out more detailed information following an audit finding

shadi: Linking to Understanding documents, but tutorials also help connect developers with the required information

Quick start guides

shawn: Not necessarily done by role but done by task

sharron: Good to do one for project managers or 'how to integrate into project'

shadi: Role or task is a way to think about it. Overlapping responsibilities but what does each responsible individual need to do?

vivienne: See a range of role development but could be one person with multiple roles or many different outsourced teams with little communication. Range of project management needs. Accessibility can fall through the gaps
... If there was a quick guide for 'designing', 'pre-implementation', etc. A sheet for each role handed to the relevant person

shadi: What is the danger with 'Top 10...'?

sharron: Danger is always that this may be viewed as being everything that is needed for accessibility. Needs disclaimer.

wayne: Aim is to provide a small set of items that will cover a wide range of issues

vivienne: How do you persuade someone to use good resources?


Tuesday

Confirm agenda

Shawn: We are left with key question of whether newbies are inlcuded in the QuickRef rejig. If not, what resources do we want to include? Are the Quick Start Guides separate from rejig? or can it be part of?
... propose excercise to imagine if newbies are not a target audience what resources do we propose for them.
... that would be morning activity, leaving the Dynamic planning guide to the afternoon. Also the video brainstorming.

Relation of QuickRef rejig to Quick Start Guides

Shawn: Is it feasible to expect the QuickRef to provide guidance for those who entirely new to accessibility? Now have Tutorials, WCAG Overview and other intro material that has not been aggressively promoted. Thoughts?

Eric: I do not think that people who are quite new to accessibility to be expected to use WCAG directly, even with a Quick Ref. If you are entirely new, you need background information and scaffolding to get to where they need to be.

Kevin: The word scaffolding is important there. If someone ends up there inadvertantly, they will need a signpost, banner that points them to what they DO need. New to accessiiblity? Go here, read this, etc

Vivienne: Is the QuickRef one thing? or a series of things

Shawn: It is now - its formal title is How to meet WCAG 2.0

Vivienne: I would never send anyone new to this document, it would terrify them.

AWK: Not as it is now but it can be reconfigured.

Shawn: Do we want to envision what would be needed by newbies or simply accept that this document is not where people should start.

Vivienne: If it looked more like the AccessIQ interface.
... I would not hesitate to send people there.

<yatil> http://www.accessiq.org/web-accessibility-wizard?keywords=images&items_per_page=20

<shawn7> Sharron: even though first page is nice, still the results are intimidating

<shawn7> ... even Loretta said this is not meant as intro

Eric: We need to make clear lines about what these documents are meant to do. The Quick Start Guides are like helicopters and the QuickRef is like a carpool.

Kevin: What do people need? There is Why and there is How.
... QuickRef is I know what I am doing in general, need specific guidance.

AWK: QuickRef has one additional requirements. It talks about the SCs and how they apply. Gives different scenarios and is the only place where you get the AND relationships as opposed to OR relationships. Provides a translation layer between the Techniques.

Shawn: How does that relate to whether it is someone new to accessibility?

AWK: I am not comfortable with the term "newbie." People may be quite accomplished technically but unfamiliar with A11y. They would not self-identify.
... if there is a gateway page, having a person routed to "newbie" material may not be what they are looking for.

Shawn: We will have users who just want to be told what to do to achieve the task of meeting the requirements.

Vivienne: User behavior is so various that it will be difficult to plan one way to get the info.

Eric: If on the QuickRef, the user enters a term like "Carousels" they will also get a link to the Tutorials.

Wayne: People aren't newbies for long

Shawn: Sometimes they are not familiar with all of the resources however and may not know how all the tools and resources interralte

Eric: They should be agnostic to user level - they may not be what we think or even they may not know how much there is to learn, how resources are changing, etc

Wayne: So much "newbie" stuff can be an impediment to actually using the material you really need. We should be cautious in the design not to front load with verbiage that is not useful after the first time or two.

AWK: People expect the documents to be badly presented, it is a barrier and people may be discouraged from going further.

Vivienne: If the intro is always there, I want to be sure I can type in the search term and get the info I really need.

Shawn: So the question is do we want one place to start - what the QuickRef is meant to be.

Sharron: What is the Overview?

Kevin: If it what comes up highest in the search engines, maybe that should be the palce to start.

Eric: We need a page where we can point people as a place to start. WCAG at a Glance has some of the elements we need. We need an overview, a search, and a starting point url on one page.

Kevin: The QuickRef is more of a tool to help developers constrain the info to their immediate need - what do I need to do?

Sharron: +1

Vivienne: When I search for WCAG 2.0 Forms, I get all kinds of other references and tutorials, not W3C.

Shawn: So how braod soe it have to be? Does it include ATAG and UAAG?

Eric: Possibly. There is a lot of overlap.

Shadi: Starting point could be the WAI website

Shawn: Biggest issue is that people don't know what resources we have, maybe an improved search of the site.

Wayne: let's scope this. Yesterday, we were talking about creating a tool for developers to land and learn how to modify web sites to improve the technical accessiiblity of their site.
... we can pull it up so high it is impossible to do. Let's just think of a landing point for them and solve the other problems later on.

Shadi: Yes I agree that we should separate the notion of a starting place from what we are trying to do with this QuickRef.

Eric: The difference is that right now, you eliminate what you don't care about. This one should be for those who know what they do care about and are looking for - may even link to the Eval Tools.

Vivienne: How do I find out then about what I should care about (know what I don't know?)

<Zakim> AWK, you wanted to ask if we have a map of what all of our resources looks like

Vivienne: may not know the right terminology to understand what I need.

AWK: We may not even know how to tell people where they are going to understand WCAG when we do not clearly know the resources and how they are related.
... try following links from the Overview, there are circular references, etc

Shawn: We have not integrated new resources into the existiing ones, don't necessarily know how they fit together.

AWK: The survey results indicate that most people don't even know that many of these resources exist.

Shawn: The fact that people don't know the resources exisit is a central point.

Vivienne: Is there a pictograph? I use it in training

<shawn7> http://www.w3.org/WAI/intro/wcag20

Shadi: We might be more effective to simply focus on the content author's needs
... in order to get the QuickRef guide done

AWK: We may not need to worry about all these audiences

Shawn: I agree with Andrew

Sharron: We are conflating the two issues: One is the fact that there are useful resources that no one knows about and the other is that we want to make this one (meant for content authors and evaluators) easy to find and use. We are conflating those two things

Shadi: We need to care about how much of a buzzword that WCAG is, how often it will be searched for, and how to redirect them to what they DO need.

<Zakim> AWK, you wanted to say we worry too much about certain groups (e.g. policy makers)

Shadi: it is a map that is perhaps needed. The branching document. Where do we want them to land may be a separate project from teh QuickRef

<Zakim> kevin, you wanted to talk about navigation

Kevin: What we are trying to do is make the navigation work more usefully for our varied audiences.

Kevin: we need to make our navigation work more effectively

<Zakim> yatil, you wanted to wonder how other organizations handle such issues

Eric: How do other consortia, similar orgs handle these kinds of problems? Look at another topic that we don't know as much about.

Kevin: Council pages, gov.uk etc

Vivienne: Many advocate for accessiiblity. In Australia because it is a government requirement, search for WCAG land on technical document and get scard and run away from the topic. Map that is presented in a usable format, allowing user interaction.

<metzessible> http://www.hhs.gov/accessibility.html is another one.

AWK: There is absolutely useful info on those pages for those who make policy, etc. But some aspect of that is useful to everyone ...a Venn diagram may help figure out what those audiences are and how to create the resources and present them in useful ways. There are tools that are so useful for testing navigation.
... measuring what they do as a result.
... why not allow that?

Shadi: It is complex, but the Venn diagram is a useful alternative for helping people find where they can find information useful and relevant to them and their tasks and goals.

Shawn: Let's break, come back and focus specifically on the QuickRef tool.

QuickRef redesign

Shawn: looking at this, do we want to change?

AWK: The QuickRef takes the place of a simple check list that we don't have.

Shawn: In the analysis that we have now is the ability to print a quick checklist

Kevin: Is the question whether supporting newbies is out of scope of the QuickRef tool?

Shawn: Yes and it seems that we have agreement that they are not a primary audience although we are aware that they might land on it. So Andrew is that in sync with what WCAG-WG will agree with?
... and that communication of accessiiblity basics is not a primary goal. Would they agree?

AWK: So we are saying it is for, content authors, developers, evaluators, etc? I tend to relate evaluators to developers. Overarching goals
... may be too overarching

<AWK> Goal: Improve the experience of quickly filtering and viewing WCAG 2.0 resources related to a developer's specific needs.

Sharron: +1

Shawn: And to capture the earlier made points - I know what I need and want to know how to find it while not losing sight of what they may not need but should be made aware of.

Kevin: And add the awareness of other WAI resources, like tutorials

Shawn: One place to send everyone is no longer a goal

Eric: We can consider what QuickRef can do for evaluators

Shawn: Later, let's look at goals
... we are focused on the fact that people are looking for one piece of information and help them find that info. But also want to help those who are simply exploring WCAG

AWK: We want to build something great but do we want ALL authors to land there?

Kevin: so the goal is to provide all the information that an author may need in one place

AWK: The consequence is that there is the compulsion to put key talking points "stable standard, referencable, blah balh blah: that make developers cringe (and retreat)

Shadi: Maybe it is not combinable to include evaluators with the resources for content authors
... have there been discussions in WCAG-WG to develop resources for evaluators?

AWK: Nothing new is planned

Shadi: The presentation of failures? As it is now, they are presented within the Techniques documents, but what if they were able to be exposed alone, without the related text.

Shawn: Could you not simply filter for the failures?

Shadi: but is there the risk of making that a case where I don't have these specific failures, so I am OK?

AWK: We have a very clear challenge in what we mean and how to account for exceptions.

Eric: yes there is no clear way to describe those

Shadi: In WCAG docs, the 'Accessiiblity support" rhetoric is largely focused on developers
... are there small thing we can do to broaden that?

AWK: I don't know yet what those small things are yet. I would like to continue to analyze the data and see. I like the idea that it would let me see only the failures. I would like to be able to say I don't even want to see general techniques.

<vivienne> i would love there to be some kind of reference geared toward evaluators as well

AWK: depending on who you are, you don't want to ahve to wade through general techniques if you are looking for specifics.

Shawn: Always afraid that they will forget that there are general techniques as well.
... perhaps have erred on the side of caution

Shadi: Evaluators may not be of the same level of targeting as the developers.

AWK: If there are things that will make it more clear for evaluators, we should talk about it.

<vivienne> evaluators also want quick reference to techniques to refer their clients to

<vivienne> not just techniques but also other resources such as the tutorials and best practice suggestions

Shawn: One point: Opportunity for additional information in Understanding Techniques to better support evaluators.
... Second point is for QuickRef to filter and provide info for evaluators

Wayne: With the "Or" sections of the Techniques, evaluators can help them determine which is best in their environment.

Eric: What will evaluators get from this? We do not want to conflate this as a resource with the WCAG-EM Tool.

Shadi: They are quite different

Eric: But they do not know that from the outside

Shawn: We may need to explore that more and have data from the survey where more than one third of the respondents were evaluators
... so we need more analysis to figure out what they need.

Shadi: Use cases and the development of them may be the next steps.
... can get that feedback and see how well those goals align with what we are providing for developers.

<vivienne> I think evaluators use the resources for 2 purposes - continual education and updating on changing techniques/failures etc., and then resources to refer their clients to.

AWK: I would make the conjecture that if the teams were actually doing their jobs as they should be, there would be Quality engineers looking at their progress within the development process. Maybe those people are simply external, hired QEs. I don't see what is different from what internal dev teams need that is that different from what external evaluators might need.

Kevin: From an evaluators POV, give me the techniques and the tests for each one

Shadi: I agree there could be an overarching term that includes QA whether external or internal. QA is another role and has a slightly different approach than developers (Probing, looking for failures rather than looking at development solutions)

Eric: Just not finding a failure does not guarantee that you fully conform.
... as far as I know, what is represented in the QuickRef now are the different situations. It is not done anywhere else and I think this is valuable.

Wayne: If you follow any one of the complete techniques, you have met the requirement, that is what sufficient means

Shawn: Subproject may be needed to better define the needs of evaluators
... leave evaluators for now and document their needs.

Shadi: There are more unknowns. We know more about the developer needs and less about the evaluators.

Shawn: What is the "advice on which techniques to prefer?"

Eric: Which techniques fit best into their dev environment, give developers ideas about what is more modern techniques, which are more useful for thier specific needs?

Shawn: greatly appreciate the brainstorm but this seems out of scope.
... as we wrap up are there other things with collaborative potential that we should consider?

Shadi: Evaluators sometimes recommend techniques, does that belong in the list of what evaluators are looking for?

Shawn: Yesterday, Andrew suggested we try to get goals and audience settled by end of November. Sharron suggested we try to do it sooner

Shadi: It has to do with the fact that it must go through two groups. Maybe we could get an intial framework and starting point will faciliate the process.

Shawn: Our next steps will be to document evaluators needs and bring that to WCAG

AWK: What are the specific tasks that we want to facilitate?
... rather than these broad use cases, can we propose some specific tasks...help me find what has change in WCAG Techniaues

Kevin: The use cases can drive the task analysis

Dynamic Planning Guide

<shawn> https://www.w3.org/WAI/EO/wiki/Dynamic_guide_for_planning

Kevin: Reads goal from wiki...leader could be project planner, commissioner, idea is provide focused support. Audience is similar to the Strategic Planning doc and personas have been identified.
... case studies need more development but are fairly straightforward
... and clearly related and personas linked within the wiki analysis page
... goal is to customize for varied users according to their specific needs
... concious of need to link the way the user self IDs and the way the info is visually presented. Or could do according to a user journey.
... would identify actors, stages and create a matrix

Shawn: Do you envision that when the Dynamic Planning Guide is done, these other docuemnts would not exist, but would be fed into this and served up as needed?

Kevin: It could be but the question is do you want that to be the output. As they are now they stand alone as broad general advice applicable to many situations.
... could carve out pieces certainly but not all of it will be relevant to all types and sizes of organizations.
... will have different questions to answer depending on many factors.

Shawn: this is a key big thing to figure out. Doubtful that we would have both a static and a dynamic document.
... maybe we have one thing, and can print a long version, a short version, or you can customize it.

Kevin: That is more about positioning.

Shadi: Sounds like an awful lot of content development

Kevin: Yes there is an awful lot of content development. Agile vs waterfall development styles for example, would have different content as output

Shadi: How much we already have that you are not already finding. Maybe the Dynamic Guide does what the QuickRef does for developers only for planners.

Kevin: I am aware of that but my difficulty is that really we have very few docs that refer to planning. If you want to talk to me about where I am and my specific situation, we must contextualize.

<shawn> Sharron: first identify what we already have. tehn gaps on what we don't yet

Shadi: The goal is to help people find resources that we already have, not to create new/more/additional resources

Shawn: So we have been thinking of how to make the Strategic Planning doc more dynamic, what if we approach from the other side. Like Quick Ref helps developers find resources, why not help planners find other resources

<shawn> Shawn: if we broaden the scope a bit, it might lighten the work (in writing new content)

<Zakim> shawn, you wanted to say is yur org convinced to do ax. if not - business case, training...

<Zakim> shawn, you wanted to say open

Kevin: Or we creating a dynamic guide to planning or a dynamic guide to exisiting WAI resources

<yatil> Kevin: I think it would be beneficial to give people little pieces of content during the process and give them a list of references at the end.

<yatil> Jon: So, a tool for aggregating the content. If we have a pointer for agile or waterfall, we need to change the content to accommodate this. I develop a high-level overview for small, medium, large organizations. I think we might have the content.

<yatil> Sharron: Jon and I can provide Kevin content to fill the gaps so people can easier engage.

<yatil> … People probably don’t engage as it’s static.

Shawn: Illustrations especially around this topic are hard! Harder than heck. We have tried to redesign logos, etc. Tried to do illustrations gotten very few through.
... not saying to abandon idea of illustrations but just be mindful of the difficulty

Shadi: What happens after I have answered all these questions, where does it take me?

Kevin: if we are taking a tailored list of our resources, it may not link to the entire resource, but a subsection of it.

Shadi: Why not have the same section titles that we have in the Strategic Planning Document?
... with annotation within the final image checklist

Eric: Having it short and as expand/collapse is great - the three stages, case studies and it will be quite appealing

Kevin: we have the risk of creating modules that may not be relevant.
... can potentially be asking the wrong questions
... Initial idea is on the wiki. The idea has moved to include only the key actions that are relevant to that particular user. Saving as a progress report is a possibility , using the tool more as a tracking doeument for your planning progress

Eric: or to just be able to save your progress so all does not have to be done in one sitting.

<Zakim> yatil, you wanted to say (technical) how to implement as metadata? and to say printing

Eric: If we get them through the questions, it would be great to be able to print it, stack it and hand it to your boss.

Kevin: Concerns with that is that it is not in fact the Plan but the map to make the plan - that is a different thing.

Eric: yes agreed but to have that as a printout wouldbe beneficial. Having the blurbs inserted as metadata so that if the source document changes, the changes are reflected in the displayed blurb.

Kevin: Implications for the backend - how to have multiple key actions that are tagged and appear only in specific situations. Data is pulled into component pieces and only displayed for certain users
... I think what I need to do now is document what the requirement might look like - talk about the modules, serve up blurbs based on response, etc. Need to define the tool to do that. Other task is to audit the content and seeing if there is more or what subsections might be delivered invarious scenarios. Also identify questions to ask and additional key actions that may be needed. Finally what

additional modules may be needed.

Shawn: Being aware of the need to limit the amount of new content we will be able to develop. Want to be eager to do due diligence on Start with Accessiiblity and how we might address that

Kevin: My review indicated it was quite tied to project methodology and doesn't talk much about agile but is largely confined to build process.
... there is more to pull out fromthat within that stage.

Shadi: How relelvant is the development process to the Strategic Planning document and process? Those kinds of assessment, training, etc will ahppen no matter what kind of process is in place.

Kevin: Some of QA and team structure so Roles and responsibiliies may be affected

Shadi: It is useful to understand how useful it is to stay at this level
... next level down is increased by a factor of x

Kevin: agreed and I will not want to go into too many levels of depth

Shadi: We want to remain mindful of where we want to keep the level

Kevin: and just address the key differences that are in play depending on your development methodology

Shadi: There should be a way to say "Please just show me a general generic plan" I might go and decide that I want a customized version if it is interesting enough.
... but if I don't want to answer all the questions, I want to just step into just give me the list, no need to answer questions

Kevin: There may be an opportunity to then see who chooses the customization route

<yatil> Kevin: I will do some paper prototypes to reflect the thoughts we talked about.

<yatil> Shawn: We need to be clear about the scope pretty quickly.

<yatil> Kevin: We have a top-down approach from the document. I think we should come from the key actions. What would make me think about those key actions, what makes them important.

<yatil> Shawn: Some key actions might not be too easy to ask.

<yatil> Shadi: In early incarnations there were more different types of organazions, we could revisit that when we have the tool.

<yatil> Shawn: We needs to see how many questions we need. 3, 5?

<yatil> Kevin: Ideally, three questions would be a great start.

<yatil> … Overall, there may be about 20 questions which are revealed one after the other, depending on the section the user is in. Don’t want massive amount of questions.

<yatil> Shadi: 4 to 5 questions could bring us really far.

<yatil> … TFL does that pretty neatly.

<vivienne> do you have an idea of the questions?

<vivienne> might have missed something as IRC keeps dropping me out

<kevin> Identification of the questions would be one of the important stages of analysis

<yatil> … they manage to reduce the questions to a few, like ground-level entrance without asking what wheelchair you use.

<yatil> … We don’t need to cover every situation, but get broadly into the right direction.

<yatil> Shawn: If we look at the complete document (Shawndi mode), we could show the tagging.

<yatil> … Small, medium, large, for example.

<yatil> scribe: EricE

<yatil> scribeNick: yatil

Reinaldo describes the brochures he did in Brazil.

<shadi> https://www.w3.org/WAI/EO/wiki/BenefitsVideos

<yatil_> Shadi: We want to create really short videos 1-2 minutes that demo the benefits of accessible websites.

<yatil_> … for examples making the click targets bigger or adding captions.

<yatil_> … use cases.

Videos

<yatil_> Kevin: I think of a pattern for the videos, like starting with the accessibility and then having a punch line that it has additional value.

<yatil_> Wayne: Responsive design would be a good topic as well.

Eric: We could zoom onto the mobile and then zoom out and it is a large monitor with a vision impaired user.

Kevin: Higher contrasts.

Vivienne: Stopping content would be useful as well.

Shawn: Non-disabled use-case?

Shawn: time outs

Shadi: complex information, ability to control spacing

Kevin: tricky to show hidden disabilities

Vivienne: captions

Kevin: alt text, low bandwidth

Vivienne: Keyboard only, seniors

Jon: using slide presentation and keyboard controls

eric: empty mouse batteries and no more ability to navigate

Wayne: Popup windoews on a gurney

Renaldo: Gestures, keyboard

Vivienne: keyboard visability, where are you if you don't use the mouse. Focus

Sharron: Power users, web apps

Shawn: Yes I am thinking of a call center staff, irritated cause he must revert to mouse

Jon: Tabbing through stuff more quickly than using a mouse

Eric: A disabled power user "give me that I can do it faster"

Evangelos: For power users, working on desktop, web applications
... that is me when I am developing

Shadi: Onscreen keyboard on kiosks, TVs, XBoxes

Shawn: 2 things...power user, repetitive keystrokes, not programmers but with their own apps. Another was to consder the advntage of a pattern is if you break the pattern even more powerful.

Vivienne: VoiceOver on an iPad, when you are cooking, the user gets the info when your hands are busy etc

Jon: translation device on the phone
... Dragon

Eric: Siri was developed for the blind now is used by all

Shawn: Small link targets example was for outdoor utility workers in Wisconsin

Sharron: gloves etc

Kevin: Calendar app and can add tasks etc with voice activation. Alternative is dark room, passionate noises, allowing wife to add to husbands calendar

Shawn: how many will we do?

Shadi: Somewhere around 8
... Think about various disabilities, scenarios, etc

Kevin: clarity of content, readability for cognitive. Clean interfaces, how to show both sides of the equation

Shadi: Saying a11y helps more people is tricky since usability is a factor.

Jon: When closing a browser window and asks you to hold this...did you mean to hit this key or did you mean to do another? Second guessing the user...are you sure you want to leave this page? It benefits people with CI. Wouldn't it be useful for all users

Eric: I think of readability function that only gets the article, using ARIA to display only the center content, stripping out ads and other distracting content.

Shawn: May be beyond scope but might show how something developed for disabilitiy - vibrating pagers for example. As mainstream realize the value, price comes down and are included in all phones

Shadi: The zoom function might be an example that can be related to the web

Shawn: Readbility use case, a busy person needing to find specifc information. I need a fireman, a doctor, poison antidote

Vivienne: error prevention and forms and how that benefits everyone, Error in phone input erases all info.

Shadi: Laughing because that is exactly what happened to me yesterday.


Wednesday

organizing for future work

Shawn: staggered surveys each week

Vivienne: Milestones, gant charts to help prioritize

Wayne: need to be able to abstain from what they aren't interested in

Michael Cooper: Once a month, or every other month hold joint meeting with WCAG-WG and EOWG

Shawn: for discussion of tutorials and QuickRef

Breakouts: 1. GitHub training, 2. planning

Sharron: Items to include in planning: 1. participant review 2. engagement (weekly surveys, phone conferences, etc) New rules re: mandatory telecons vs survey, comments, other kinds of engagement 3. list of documents, timelines, level of coordination with other groups or individuals

Shawn: Need to wrap up 3 planning docs, 2 tools and 5 tutorials that have to be brought to final form
... start new projects which include the QuickRef rejig, dynamic planning guide, and QuickStart guides. Also Accessibility/Usability doc

<shawn7> http://www.w3.org/WAI/DEV/deliverables

Shawn: We have so many cool projects that we have wanted to do for years...

Sharron: yes, and we have to take full advantage of that by ensuring that all participants are fully engaged
... who do you feel is currently fully engaged and/or prospective new participants?

<shawn7> ACTION: shawn followup with Scott Hollier [recorded in http://www.w3.org/2014/10/28-eo-minutes.html#action01]

<trackbot> Created ACTION-303 - Followup with scott hollier [on Shawn Henry - due 2014-11-05].

Shawn: new participants: Vivienne, Scott Hollier, Lydia (from A&M), Brent from Pearson

<shawn7> ACTION: shawn followup on Pearson and Brent [recorded in http://www.w3.org/2014/10/28-eo-minutes.html#action02]

<trackbot> Created ACTION-304 - Followup on pearson and brent [on Shawn Henry - due 2014-11-05].

Sharron: Brent is waiting for clarity about Anthony Fernardo's participation.

Shawn: I will ping the AC rep

<shawn7> ACTION: shawn follow up with twitter contact [recorded in http://www.w3.org/2014/10/28-eo-minutes.html#action03]

<trackbot> Created ACTION-305 - Follow up with twitter contact [on Shawn Henry - due 2014-11-05].

<shawn> ACTION: Shawn follow up with Liam [recorded in http://www.w3.org/2014/10/28-eo-minutes.html#action04]

<trackbot> Created ACTION-306 - Follow up with liam [on Shawn Henry - due 2014-11-05].

<scribe> ACTION: Sharron to follow up with Howard after AHG [recorded in http://www.w3.org/2014/10/28-eo-minutes.html#action05]

<trackbot> Created ACTION-307 - Follow up with howard after ahg [on Sharron Rush - due 2014-11-05].

Shawn: also on our To-Do list is to update the policies page. Jan is interested in helping

SHarron: Seems like a survey would say here are our 8 work porjects. Which of these are you most interested in? Which are you least interested in? Then list each and ask "Where are you in your review?"

ShawN: We should assume everyone needs to look again at most of the documents we just approved as drafts.
... but some are easier than others

<shawn7> evaluation tools list http://w3c.github.io/wai-eval-tools/

Summary of Action Items

[NEW] ACTION: Shawn and all change WCAG Overview to WCAG 2.0 Overview [recorded in http://www.w3.org/2014/10/27-eo-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/10/30 18:55:16 $