The meeting began with a recap of CSUN highlights shared by those who had attended, inlcuding increased attention to procurement resources, great interest in Easy Checks, and a general feeling that the filed was maturing. Because there was such low attendence at the F2F, the group must consider whether we want to plan to meet at CSUN again next year (so that space can be reserved) or pass and find other venues for face to face meetings. Next Shadi asked the group to consider the development of a new document for helping toolmakers include accessibility evaluation features. Shadi particularly asked for help with the framing of the document, especially the title, the abstract and the introduction. The group brainstormed titles that more clearly targeted the audience of tools makers. Discussion followed about seeding the WAI-Engage wiki with policy and procurement resources. Caution was expressed about being clear that this is not legal advice and to steer clear of contract language. Otherwise, the idea seems useful and will be pursued. In exploring why the availability survey was not being completed, we found several people locked out from their log-in. Once that is solved, Shawn urged everyone to keep the EO participant attendence survey up to date. Next the group looked at the newly organized EO wiki and associated actions - now structured by topic rather than by person. Members are encouraged to visit the wiki once or twice a week, search for your name associated with a topic and then search for "Who Else." If it says everyone, a response is required; if it says anyone, you are encouraged to comment - even to agree with previous comments or say you have no opinion. Going forward, the meeting agendas and summaries will also be found on the wiki for your convenience.
Shawn: For F2F, Jan, Sharron, Shawn attended and are here now... any thoughts?
Jan: I wanted to tell this group that Pearson announced for three accesssibility positions at CSUN. 2 Senior level management and 1 assistive technology specialists who will work with Suzanne Taylor's group.
Shawn: You can send those to the WAI-IG
Jan: They have had a great response and she will be able to hire three people with complementary skills.
Paul: Found increased awareness and professionalism in the web track.
Jan: I went to a session on color issues from NC University - they have created a tool that runs on images as well as text. I will find the link in my notes and put into IRC.
<Jan> Color Contrast Analyzer Tool from NC State University: http://accessibility.oit.ncsu.edu/tools/color-contrast-chrome/
<Jan> Greg Kraus was the presenter from NC State on the color contrast analyzer tool. I believe he actually coded it.
<Jan> and here's the link to NC State's presentations at CSUN 2014: http://accessibility.oit.ncsu.edu/presentations/csun-2014/
Sharron: Jan and Brent from Pearson put together a panel of people of all ages telling their experince with computer based testing that was not accessible. It was powerful and even though it was the very last session on the last day, room was full and people stayed late to ask questions and engage with panelists - terrific!.
... person next to me said best session of the whole conference. They spoke about about real outcomes for people who are locked out of testing situations and the impact on lives and careers. It was emotionally moving, informative
Paul: I found there was much more information about procurement and contracts.
Sharron: Well, for the record, I was frustrated by the fact that we did not have greater participation at the f2f. Perhaps we should think about meeting after all the presentations and preconference sessions have ended - but it's a weekend, so will be a challenge, too
Shawn: Judy asked me if we planned to meet again at CSUN next year since we will have to plan for space
... let's think about and plan for that.
<shawn> https://www.w3.org/WAI/EO/wiki/Easy_Checks#March_2014_changes
Shawn: We have a few changes to make from our session - pretty simple changes
... Bim and Andrew weighed in on that, thanks for your comments
Andrew: I am wary of expanding acronyms in headings as it makes it quite long sometimes.
Sharron: Suggest editor's discretion
<Andrew> +1
All: OK with that
<shawn> More visible, and stronger statement that this process is not definitive, and will have to do more...
Shawn: The issue that this is just a start, some in our attendees thought this needed to be even stronger. Maybe we need to make this statement in each section, despite the danger of being repetitive.
... so we need someone to suggest that wording.
Sharron: I'll take a crack at it
Shawn: Next suggestion was to provide a way to record and track findings over time. Is that something we want to do soon, or put on a list for the future?
Andrew: Wondering how prevalent is that wish to have a list like that. Seems like folks might have their own notepad or other method of tracking,
Sharron: We might be at cross purposes: One on hand we want to emphasize that it is not definitive but providing a checklist might make it more official seeming
Jan: Would it be unreasonable to give them a sample checklist without endorsement?
Shawn: I agree with Sharron about the EasyChecks recording document but would consider looking at one for all of WCAG.
Jan: Anthony provided a checklist at CSUN that he used for QA that we might consider.
Sharron: Would he share that with us?
Jan: Where shall I ask him to send it
<Andrew> I agree with not encouraging a checklist for easy checks as they are not inclusive.
Sharron:Regarding the EasyChecks, everything I heard was thank you, thank you, we needed something like this etc. In the preconfeence session I led, there was excitement about the tutorials
Shawn: To the EO list
... I think we should fast track getting the cautionary language in the sections
... where should it go, how should it be presented, let's get it in there right away.
<Andrew> should it just be in the "using" section or in all sections?
<shawn> [patting on backs all around for EOWG resources]
Shawn: Seems like we must have to put it in every section
Andrew: Yes I can see that, I tend to jump to what I am looking for
Shawn: If we have it stand out, the first few times they will notice it and after that they will mask it out cognitively
<Andrew> maybe [*NOTE:* warning text] at bottom of each section before the expand options
Shadi: Scope creeping possibility. If we put warnings in each section can they be contextualized for each thing.
Sharron: That makes sense
Andrew: Doesn't that happen in the "Learn more about..."
Shadi: It is a bit different for each
<shawn> https://www.w3.org/WAI/EO/wiki/Alt_guidance
Shawn: Background on this is the discussions around the HTML5 document, what guidance should be provided in the document itself vs elsewhere. latest feedback we have gotten is to create a stable page that can be pointed to from the document.
... very stable meaning the URL, changes would go through WG review, currently thinking it would point to Images Tutorial and Techniques.
Andrew: I looked at the page earlier and was unsure about the target and objective for the content
Shawn: Goal is to have a stable pointer for HTML5. At this point, they do not want to point to Tutorials because it is not done
Andrew: For technical people, then?
Shawn: I am not 100% convinced that this is the right way to do this. Do we forsee anything other than WCAG TEchniques and Tutorials that we would EVER point to? If not, forgo this page and ask them to point to those - the Techniques and the Images Tutorial...thoughts on that?
Shadi: When you say Techniques, do you mean How to Meet?
Shawn: Not sure if we would just list them or what? If this page does happen are we comfortable being the WG that approves it?
<Sharron: +1
<Bim> +1
<Andrew> +1
Andrew: Seems straightforward
<Helle> +1
<shawn> https://www.w3.org/WAI/EO/wiki/Evaluation_tool_guidance
<shadi> http://www.w3.org/WAI/ER/WD-AERT/ED-AERT
Shadi: The document has shifted a bit. It is now called "Features of web accessibility evaluation tools: Guidance on the development and selection of tools"
... the purpose was for makers of accessibility evaluation and even QA tools - they have have been increasingly exected to provide some accessiiblity evaluation within their tools. There is a wide array of tools and they provide very different levels of support - in terms of functionality and even the Guidelines they support. Sokme crawl, some don't; some have log-in, some don't; they report differently etc
... this document is meant to inform tool developers how to support accessibility evaluation and to incorporate better support in their future releases.
... the idea here is not to assume that a single tools will contain all the features, but to identify which ones do support which features. We will end up with a kind of matrix
... a secondary audience is to create a taxonomy for tool functionality and it could facilitate the comparison of tools.
... it is listed in the wiki, we have the "Selecting..." document that will be updated. That one is meant for those who need to choose a tool and we expect that the selecting audience may also refer to the "Features..." document, but that is not our primary target group with this. There will be a strong relationship between them but we will focus today on the "Features..." document an the tool makers.
... at CSUN I showed this around to people, especially tool developers. Many of them want to distinguish themselves from others and they may want to get engaged in fleshing out the features and my guess is that this may happen quickly. We would like to publish a draft to get that input. So we are asking for framing of the document, especially the title, the abstract and the introduction.
... how well do we communicate the purpose, how clear is it for the reader to identify whether or not this is a document that they can use?
... is it clear what we want to do today?
Paul: It is not quite a flow chart, and not quite a feature matrix but can include both?
Shadi: A flow chart to decide on a tool?
Paul: Yes
Shadi: No that is not the intent, it is mostly meant for tool developers.
... although we are not creating a normative document, it is meant to be informative.
Andrew: Paul's question would point to the "Selecting.." document, then and not this one, if I am understanding correctly.
Shadi: It is two sides of a coin. While this is meant to inform tool makers about what features they might include, it could also guide the technical person who needs a tool about what to look for.
Andrew: You seem to be talking more about semi-automated tools,even though the intro mentions a wider range of tools, inlcuding single purpose tools.
... am I misinterpretating or not read closely enough?
Helle: Those things about semi-automated or automated tools and the various ways of approaching evaluation in different tools was not clear to me about the purpose here.
Shadi: We were contemplating listing the WCAG SCs
Helle: In that case you would be saying here is what you need to check rather than saying this is what the tools do. So more of "How do you check for this?" rather than saying "this tool can do that."
Shadi: The techniques describe the process so this is not meant to be a "how-to" guide. We did not want to just reiterate the WCAG.
Helle: But won't you need to say "a tool is capable of doing this but that must be done by manual check?"
<Zakim> Bim, you wanted to say that
Bim: The apparent mis-match between what is described at the beginning of the doc and what is in the body, it may be a matter of understanding. It is mentioned but perhaps the terminolgy is understood a bit differently and we should tighten it up. Manual checks are mentioned ... I assumed that these would include single item checks. Secondly I want to agree with Shawn.
Shadi: We are at the very early stages of the document and it will morph and change quite a bit. We did not intend to overlook individual checks, may just need to further clarify.
... need better examples.
Shadi: we expect that this document can be referenced by those who are not focused on accessibility. They can begin to include these features in their tools that may be used for other purposes and to help them understand what features are needed for useful accessibility checks.
Shawn: Several points. First you really want to clearly focus that your primary audience is people developing tools. The clarity of target audince must be differentiated. For example the use of "selection of tools" in the title may be too confusing to differentiate this audience from the other one. Suggest that we do a title brainstorm:
<paulschantz> +1 yeah, that was confusing to me
<Andrew> +1 to differentiating between audiences :)
Shawn: one way to to that is the title. would suggest removing "and Selection" from the title. Suggestion in IRC
<shawn> Web Accessibility Tool Development Guide
<Bim> How about including the word evaluation in Shawn's proposed title?
Andrew: and could use the subtitle to further clarify
<shawn> Web Accessibility Evaluation Tool Development Guide
Shadi: Does it need to be two separate docuemnts?
Andrew: Yes
<Helle> +1 two docs
<Sharron> +1
Shadi: There is great overlap, so we were unsure it that was the right approach
Andrew: Separation will also make it easier to write the one for tool makers
SHawn: And you can certainly point between the two
Bim: The more technical or expert selector might find use with this document but most of the tool selctors are not experts and would be confused by this
<Andrew> +1 to Bim - experts probably already understand the tools selection process
Shadi: We want to reach out to tool makers who may not at this time include accessibility evaluation in their tools but may want to.
<shawn> Web Accessibility Evaluation Tool Development Guide
<shawn> Web Accessibility Evaluation Tool Features & Funcationality
Shadi: so let's look at the title suggested by Shawn. It seems that this title will Guide me to the actual development of the tool
<Andrew> Requirements for a web accessibility tool / a guide for tool developers
Howard: I worry about the current title putting Features first that it might draw in people who were looking for tools.
Andrew: Yes, I agree with that
... how about Requirements for ...and subtitle a guide to development
<shawn> Web Accessibility Evaluation Tools Features Guide for Tool Developers
<shawn> WAETFGTD
<Andrew> Accessibility evaluation tool features / a guide for tool developers
<shawn> WET Guide
<shadi> [[implementors guide]]
<Jan> +1 Andrew's title
Howard: In terms of purpose - it is to outline the features that you would want to find in a web accessibility evaluation tool
Howard: is it meant as a blueprint for developers?
<Andrew> Bim: Developers' Guide to Web Accessibility Evaluation Tool Features
<Andrew> +1 to bim
<shawn> Tool Developers' Guide to Web Accessibility Evaluation Tool Features
Sharron: A Developers Guide to Web Accessibility Evaluation Tool Features
<shawn> +1 to tweak on Bims
<paulschantz> +1 to Bim/Shawn's suggestions
<Jan> Guidance for Developers to Web Accessibility Evaluation Tool Features
<shawn> Web Accessibility Evaluation Tools Features Description for Tool Developers
<shadi> [[feature list]]
<Jan> Guidance for Developers to Features of Web Accessibility Evaluation Tools
<Bim> Web Accessibility Features List for Developers
<shawn> Web Accessibility Evaluation Tools Features Description
Shadi: What about "implementers" rather than developers?
Andrew: You mentioned that earlier, implementer to me has the connotation of user
<Howard> agree with Andrew
<Sharron> +1
<Bim> +1
<shawn> Web Accessibility Evaluation Tools Features Description for Tool Vendors (don't like it , but brainstrming)
<shawn> Guidance for Tool Developers on Features of Web Accessibility Evaluation Tools
<Bim> How about Software Developers rather than Tool Developers
<Jan> creator
Sharron: Tool Creators Guide to Features of Web Accessibility Evaluation Tools
<shawn> Tool Developers Guide to Features of Web Accessibility Evaluation Tools
<shawn> Tool Developers Guide to Web Accessibility Evaluation Tool Features
<Jan> Guide for Developers to Features of Web Accessibility Evaluation Tools
Shadi: Thanks for the brainstorms, I have plenty to take back to the group
<Andrew> just captured most of these in https://www.w3.org/WAI/EO/wiki/Evaluation_tool_guidance#Title
<shawn> thanks, Andrew! can you please also add a pointer to the minutes?
Shawn: I slightly prefer one or the other of the title or subtitle to be shorter, long title, short subtitle or Short title, longer explanation
<shawn> https://www.w3.org/WAI/EO/wiki/Procurement_Resources
Shawn: We have talked about seeding the WAI-Engage wiki with training resources and also procurement resources. At the F2F we hammered through some ideas about what that might look like. In the wiki there is a spot to debate the pros, cons and content
<shawn> Sharron: would need to be clear sterring around legal & it not being complete
Sharron: To start with the negative we would have to steer around the legal implications and the question of it being a complete resource
Howard: How much of this already exists...does WebAIM provide it? They have some studies or reference to one about policies and the relationship to accessiiblity
Shawn: Some people do put thier own policies online and that may be what this is...a link to the policies and processes that others provide?
<shawn> add action for Howard: research if other resources for procurement
<Andrew> Aust Govt - http://webguide.gov.au/accessibility-usability/accessibility/procurement-and-accessibility/
Howard: I can research what is out there. I have tried to get the City of Boulder to include it and so have done some research
Sharron: I will add some to the wiki as well
Shawn: And annotate it so we know what is distinctive about ti
... we link to Jan's rubric which goes back to the checklist for WCAG conformance
... other thoughts. Is this something we should take on as a project...helpful? risky? what are the feelings of the group?
<Bim> It would certainly be useful and is much in demand, but not sure about the risk.
Sharron: Compilation would be useful
Paul: Having a listing of "here's how some other orgs are dealing with this" does not incur much risk
Shawn: Two questions: How much time should we spend on it before we put it on WAI Engage?
... how polished?
<shawn> add action for Shawn to followup on disclaimer needed for https://www.w3.org/WAI/EO/wiki/Procurement_Resources
Sharron: Yes if we put it out on WAI and ask to contribute, we should provide a very clear framework. A few examples to demonstrate that framework would be important
<shawn> rssagent, draft minutes
<Jan> Yes - I am interested in working on this
<paulschantz> If you have a list of references from different types of organizations (governments, education systems, corporations), it would give a good idea of how others are doing it
Shawn: Yes that is where the annotations come in. Adding notes or categories
... we started having it by country. Maybe it is a table to cross reference org type, nationality etc
<shawn> https://www.w3.org/WAI/EO/wiki/WCAG_review#Techniques_for_Specific_Technologies
Shawn: wanted to remind us of the alternate wording that WCAG came back to us with that did not meet our objection. Maybe we want this in different places. I would appreciate your comments on the wiki. Encourage you to consider and add your ideas to how we can resolve this. First section is background from Feb, so don't comment there but read on and comment in the current sections.
<shawn> https://www.w3.org/WAI/EO/wiki/Action_Items
Shawn: Now that we have this organized mostly by topic with longer term stuff under people's name below. So each week, or twice a week search for your name and then search for "Who Else" if it says everyone, it is required; if it says anyone, you are encouraged to comment.
<shawn> https://www.w3.org/2002/09/wbs/35532/availability/
Shawn: Sharron is having trouble with log in, so is Paul
Andrew: There was a message about that earlier
<Jan> My login doesn't work either
Shawn: Once that password is fixed, it is an easy thing to do, please do that.
... we base the agenda on who will attend so it is a useful and easy thing for you to provide, please do.
<Andrew> http://www.w3.org/blog/2014/03/w3c-password/
<shawn> Anyone with a W3C account must now reset their password. Those that do not remember their password may use the recovery system.
<shawn> If you have general questions, please write to site-comments@w3.org.
<shawn> reset: https://www.w3.org/users/myprofile/edit/password
<shawn> recovery: http://www.w3.org/accounts/recover
<shawn> wiki
<shawn> https://www.w3.org/WAI/EO/wiki/WCAG_review#Techniques_for_Specific_Technologies
<shawn> https://www.w3.org/2002/09/wbs/35532/availability/
Shawn: We will still have regular minutes and formal minutes as now, but we would have the summary and agenda in the minutes so it will be easier to cleanup
... OK with all?