Education and Outreach Working Group Teleconference

07 Nov 2014

See also: IRC log


kevin_, Shawn, AnnaBelle, Sharron, PaulSchantz, Wayne_Dick, +1.512.731.aaaa, Jan, kevin
Andre, Hell, Eric, Jon, Vicki_(Shadi)
Sharron, Jan


<trackbot> Date: 07 November 2014

<Sharron> Scribe: Sharron

Media Accessibility User requirements

<shawn> https://www.w3.org/WAI/EO/wiki/Media_Accessibility_User_Requirements#Relationship_with_How_People_with_Disabilities_Use_the_Web

<shawn> eowg discussed options: https://www.w3.org/WAI/EO/wiki/Media_Accessibility_User_Requirements#Options_EOWG_Discussed

Shawn: Developed by HTML5 Task Force within PF there is a section that references media requirements according to disability types.
... one option is to link to the Diversity document from the Media document but we were not all in favor of that. Another option was to take the wording from the Diversity page and repeat it, were nto entirely happy with that option either.
... settled on a decision to leave the basic approach that is in the Media document, clean up the language and where appropriate, use language from the Diversity document.

Wayne: There is a cooment I made in email, that they are making different points in this document. Not as interested in the complete picture of disabilities and technology, more interested in getting right to the point of the functional requirments in this specific context.
... really just trying to identify critical functions affected by the media.

<AnnaBelle> happy to go with group decisions

Shawn: So looking at this section, any disagreements with this approach?

<paulschantz> +1 3rd approach

Sharron: Seems right to me

<shawn> Shawn: it was a preliminary decision / proposal at the f2f for review by all EOWG

<Jan> sounds good

<kevin> +1 third approach

<shawn> https://www.w3.org/WAI/EO/wiki/Media_Accessibility_User_Requirements#Proposed_Suggestions

Shawn: Taking that approach, Wayne did a pass and Kevin and I did as well. Link to suggestions

Wayne: It could be stated better in places, even for spec writers to review.

<shawn> 1. link to HPuW resource

Shawn: And it is not a primary document meant to inform people about disability so we can be a bit more lax in the wording but should strive to be sure it is accurate and clear.

<paulschantz> agreed, #1 is a no-brainer to include where appropriate

Shawn: Add link to HPwD use the web

Jan: Can you add "in depth" instead of "More information"

Shawn: Yes done

Kevin: More in depth information on tools or people? I am a bit confused by the reference

<shawn> some wording: Introduces detailed examples of people with different disabilities using websites, applications, browsers, and authoring tools.

<shawn> from first page: This resource introduces how people with disabilities, including people with age-related impairments, use the Web. It describes tools and approaches that people with different kinds of disabilities use to browse the Web and the design barriers they encounter on the Web. It helps developers, designers, and others to understand the principles for creating accessible websites, web

<shawn> applications, browsers, and other web tools.

Jan: Seems good to me as is, we can move on.

<shawn> 2, section title

Shawn: Any objection to that?
... Next is the review by disability type, but it is not comprehensive so may need to modify the language

Jan: No strong feeling but could use "Examples" in the title to show the lack of comprehension

<shawn> 3. deaf first

Wayne: And either "Example" or "Overview" works

<Wayne> +1

Shawn: Next suggestion is that they list deafness first since that will put forward that other disability types are affected by accessiiblity issues and in this case, deafness may be MORE affected by new media

<paulschantz> yes, captioning is a big deal

Shawn: Any other thoughts?

<AnnaBelle> +1

<Jan> +1

Jan: I think this is a great idea and have faced the lack of understanding that ASL is a separate language and that all content must be translated.

<shawn> 4. first paragraph

Shawn: Next point is pretty general noting that the paragraph is rambling and may nned to be sharpened

<paulschantz> +1 to cutting the paragraph altogether

<Wayne> +1

AnnaBelle: My brain cut it as I read, translated it as blah blah blah so I am in favor of sharpening or deling entirely

<shawn> 5. Cognitive and neurological disabilities

<Jan> +1 of #4 suggestion

Shawn: Section on cognitive and neurological disabilities may also need to be reviewed by Cognitive Disability Task Force

Wayne: When I reviewed, it seemed the very weakest part

Jan: They seem to combine cognitive and neurological disabilities but there is actually a different legal status.

Shawn: I think the reason it is presented together is because it is difficult for lay people to understand the difference.

Jan: Yes, but since people with learning disabilities can function as well as anyone when properly accomodated, they should not be lumped in becasue the misconceptions are reinforced.

Shawn: Can we make sure that we address that specifically in the HPwDU the Web and allow this to remain general in the Overview?

AnnaBelle: As someone who has not a clue, I would appreciate a clear distinction, but I understand it is a lot of work to separate

Jan: I agree with AnnaBelle and maybe we should leave it for future work.

Kevin: Since this is specifically referring to media use, maybe we can steer away from specific references to disability type.

Shawn: Maybe we could suggest that in this document we should not list all of those condistions and have a pointer. The list seems overwhelming here and we could suggest that they focus on the need.

Kevin: Yes I see that as being a helpful suggestion

Wayne: We have this situation where the global terminology is not fixed at all. It is a real problem to write a comprehensible statement about this. So maybe the way around it is just this. To mention the general categories and focus on what to do.

<AnnaBelle> +1 to Kevin's suggestion

Shawn: So the suggestion is not to have the long list of considerations, but simply focus on the things to be done for accessiiblity.

Wayne: It is very clear in this section but may be applied across these examples. They may just need to focus on the accomodation more specifically.

<shawn> 6. Atypical color perception

Shawn: Consider whether or not the inclusion of this section is unecessary since this is less of an issue with media, does it require an entire subsection.

Wayne: Yes it should remain so the issue does not get lost.

<paulschantz> yes

Sharron: Yes I see that as an issue with media controls

<Jan> +1 Wayne's suggestion and the addition of color blind

<Jan> ... on media controls

Kevin: If it is going to be retained, we may suggest how it is related to media.

Shawn: Can we quickly come up with a sentence to suggest?

Kevin: if you have text overlay within the media itself (not captions necessarily) but that can be an issues as well

Shawn: I will put something in the wiki and you all can revise or comment

Sharron: OK will do

Shawn: OK the next three are just about simplfying language, etc. Take a look and if you ahve concerns or take issue with our suggested rewording
... let us know

<scribe> Scribe: Jan

<shawn> scribe: Jan

Wayne: I really like the chunking information suggestions.

Annabelle: I much prefer Kevin's edited version - it's more professional

<Zakim> Wayne, you wanted to say closely check the entire document so that needs listed in section 2 are used in section 3 and

Wayne: The needs articulated in section 2 should match the solutions articulated in section 3

Shawn: We could say that section 2 is a summary and overview and is not meant to be comprehensive.

Wayne: Section 2 should not be comprehensive, but it should be complete for their document - complete enough to cover what they are suggesting. They are saying "media do this, media do that," but it's not always easy to follow why their suggestions are important. Someone who is involved in the writing of this document should just make sure that sections 2 and 3 are synched well.

Shawn: Suggest that we combine 7, 8, and 9 into one comment.

<kevin> +1

<Wayne> +1

<AnnaBelle> +1


<Sharron> Scribe: Sharron

<paulschantz> +1

Shawn: They wanted comments before TPAC but we asked for an extension. So I would like to expedite and let other EO review but send this link to the chairs with the disclaimer that EO may have further comments, but this is what we are thinking.

Evaluation Tools list

<shawn> github version https://w3c.github.io/wai-eval-tools/

Shawn: Note that the submit function doesn't work in GitHub but does in the WAI version. Thanks to Sharron, Helle, Paul and others who reviewed and completed the survey.
... Shadi and Eric are travelling but wanted to have preliminary discussion of these comments

<shawn> Text edits to intro https://github.com/w3c/wai-eval-tools/issues/6

<AnnaBelle> +1 to Sharron's suggestion

Shawn: Sharron's suggestion is to change web sites to "a web page or application"

<shawn> " if a website meets accessibility guidelines" ->"if a web page or application meets accessibility guidelines"

<shawn> s/Shawn: Sharron's suggestion

<Jan> PEAT documentation says that they released their software in the year 206 - pretty impressive - they were very much ahead of their time.

Shawn: (channeling Jon) it should actually say web content since some material is neither a web page nor an application

<shawn> OR: "websites, incuding web applications, "

Sharron: I think it is easier to understand documents that are posted to the web as a web page than it is to understand web applications as that

<shawn> Web accessibility evaluation tools are software programs or online services that help determine if a website, including web applications, meets accessibility guidelines. [too awkawrd

<shawn> Web accessibility evaluation tools are software programs or online services that help determine if web pages, web applications, and other web content meets accessibility guidelines.

<shawn> Web accessibility evaluation tools are software programs or online services that help determine if web content meets accessibility guidelines.

AnnaBelle: There is a lot of confusion in the developer world about what is and is not a web app, so I think it is important to include that language. Whether the tools do a good job of evaluating them is another question.

<paulschantz> I like web content. Web applications create and present content the same as a plain 'ol HTML web page

AnnaBelle: people would be more likely to look at the tool if we include web application.

Shawn: How well do the evaluation tools return accurate evaluation of web apps?

<paulschantz> until web page creation is all automated, automated evaluation tool effectiveness will vary

<shawn> Web accessibility evaluation tools are software programs or online services that help determine if web pages, web applications, and other web content meets accessibility guidelines.

<Jan> +1 to Shawn's comment

Paul: I like web content as a term. Until web page creation is all automated, there will be no way for an automated tool to be accurate. Custom code means that there is no way for an automated tool to know how code renders

<shawn> 2. Web accessibility evaluation tools are software programs or online services that help determine if web content meets accessibility guidelines.

<AnnaBelle> +1 to shawn's revision

<Wayne> Actually, Alan Turing and Kurt Godel proved the automated tools can never work always

<shawn> 2/ 1. Web accessibility evaluation tools are software programs or online services that help determine if web pages, web applications, and other web content meets accessibility guidelines./ 1. Web accessibility evaluation tools are software programs or online services that help determine if web pages, web applications, and other web content meets accessibility guidelines.

<shawn> 1. long list 2. web content

Sharron: 2

<Jan> I think we need Shawn's first revision with the long list because there's just too much confusion around accessibility in general, so being more specific is better, IMHO

<AnnaBelle> +1 to 1

<Wayne> 2

<Jan> +1 to 1


<shawn> +1 to 2

<paulschantz> ok, I'll go with 1

<Jan> You could simply change "pages" in #1 to "sites"

<shawn> Web accessibility evaluation tools are software programs or online services that help determine if websites, web pages, web applications, and other web content meets accessibility guidelines.

<paulschantz> grr

<Jan> +1 to linking to website definition

<Wayne> so I change to 1

Sharron: Web "content" generally refers to the information in a Web page or Web application, including text, images, forms, sounds, and such. More specific definitions are available in the WCAG documents, which are linked from the Web Content Accessibility Guidelines (WCAG) Overview.

Linked from: http://www.w3.org/WAI/intro/accessibility.php#content

<shawn> 3. Web accessibility evaluation tools are software programs or online services that help determine if <a href="http://www.w3.org/WAI/intro/accessibility.php#content">web content</a> meets accessibility guidelines.

Shawn: Comments?

AnnaBelle: It seems OK to me, no great objection.

<Wayne> If web content = page+app why not use the right hand side?

<shawn> minor - version & release date under details https://github.com/w3c/wai-eval-tools/issues/9

Shawn: Next is the suggesting for release date

<shawn> tool: https://w3c.github.io/wai-eval-tools/

<paulschantz> Agree with Kevin - keep version and release info

Kevin: I would argue for keeping release date visible. part of understanding the value of a tool is whether or not it is up to date with newer technology and techniques.

Sharron: +1

<Wayne> +1

<paulschantz> +1 keep it visible

Shawn: If it is hidden it is easier to skim the list. The info would still be there but be hidden within details.

<shawn> Text edits to filter criteria https://github.com/w3c/wai-eval-tools/issues/7

Shawn: OK will close that issue, next is the question of text edits

<shawn> scribe: jan

Sharron: These descriptions are submitted by the people who have created the tools, so we get some strange things in the filter (like "also Firefox add-on).
... there is an "other" option in the submission form and this is a problems.

Shawn: A higher-level issues is "what should we do with the "other" option. If someone puts something in "other," then it shouldn't automatically become a filter.
... We are uncomfortable with content entered under "other," automatically becoming a filter.

Sharron: This issue is reflected in my #4 comment

<AnnaBelle> I like "Features" more too

Sharron: if you look at the filters on the left-hand side, you have a list of filters - if you look at "assistance," you have a list that does not really look like "assistance." They are more related to how they report. "Features" is a better word - feature of the tool. If they don't want to use "features," then I think we still need to think of a different word because "assistance" doesn't make sense.

Annabelle: I like features more - it makes more sense to me.

<kevin> +1 for Features

Sharron: another option - "capabilities" - I think that when I open the "assistance" link that I am going to get help on how to use the tool, but that is not what I get.
... "display options" - does this work better than "features?"
... #2 - "automatically checks" - language needs to be cleaned up, but this is probably something that was submitted by the user, in the same way as #4 - so #2 is really related to #4

<shawn> submit form has:

<shawn> Supports automated checking of:Single Web pages

<shawn> Groups of Web pages or Web sites

<shawn> Restricted or password protected pages

<shawn> the submit form says "Authoring tool plugin for:"

Shawn: Instead of "authoring tools" it should say something like "plug-in for certain authoring tools" or something like that

Sharron: "Authoring tool plugin" - another suggestion.
... I think that anyone who adds a filter, those will have to be checked by us, before they are added.

Shawn: We might have to let them know that your "other" suggestions may not be added as a filter, but could show up in your description.
... Reminder - do the review and complete the survey by Wednesday.

Annabelle: Is this a different survey than I have already filled out?

Overall Work - Where we are now

<Sharron> scribe: Sharron

Shawn: We had big push to post drafts of many things in October. Now that they are posted, we will go at a more reasonable pace, one by one to have a chance to do more detailed review.
... so this is a new survey for the Tools to say that it is not just sufficient for posting as a draft, but need to do a final sign off

AnnaBelle: Sharron mentioned last week that we will do more surveys to keep us aligned and focused. Is that right?

Shawn: Yes, after Shadi and eric get back, we will release a schedule for getting work done and the surveys will be related to that.
... We want to give people at least two weeks to review, not to do too many things at once. Tools List was the first. Coming up next is the Policy document.
... once you have completed full review of the Tools list, you can begin to look at Policy. This is final approval of the Tools List look at it carefully.
... Ideally we have looked at things in advance and by the time the survey comes, there are not many comments.

Sharron: But since we looked at these so quickly it is not surprising we are stioll getting comment

Shawn: Yes that is why we want to begin reviewing Policy now
... any questions about review process or where we are?

EvalTools and ATAG

Wayne: Are evaluation tools subject to ATAG?

<shawn> http://www.w3.org/WAI/intro/atag.php Authoring tools are software and services that "authors" (web developers, designers, writers, etc.) use to produce web content (static web pages, dynamic web applications, etc.).

Wayne: I ask because I got so frustrated with how unusable they are, I rarely use automated tools. Is that captured in the eval tools list

Shawn: look at ATAG and if you have a question or comment, submit
... as it applies to this tool, it is an interesting question. Perhaps you should add an issue of whether the tool meets ATAG or WCAG
... Productive discussion, appreciate your input and happy GitHubbing to all.

trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014/11/07 15:27:31 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/appracitae/appreciate/
Succeeded: s/tehy focus/they focus/
Succeeded: s/considetions/considerations/
Succeeded: s/ahve/have/
WARNING: Bad s/// command: s/Shawn: Sharron's suggestion
Succeeded: s/Sahwn: Suggestion/Shawn: Sharron's suggestion/
Succeeded: s/ Web accessibility evaluation tools are software programs or online services that help determine if web pages, web applications, and other web content meets accessibility guidelines. / 1.  Web accessibility evaluation tools are software programs or online services that help determine if web pages, web applications, and other web content meets accessibility guidelines./
Succeeded: s/ahve/have/
Succeeded: s/Coming up next is the Planning documents, first will be the Policy document./Coming up next is the Policy document./
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Found Scribe: Jan
Found Scribe: Jan
Inferring ScribeNick: Jan
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Found Scribe: jan
Inferring ScribeNick: Jan
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Scribes: Sharron, Jan
ScribeNicks: Sharron, Jan
Default Present: kevin_, Shawn, AnnaBelle, Sharron, PaulSchantz, Wayne_Dick, +1.512.731.aaaa, Jan, kevin
Present: kevin_ Shawn AnnaBelle Sharron PaulSchantz Wayne_Dick +1.512.731.aaaa Jan kevin
Regrets: Andre Hell Eric Jon Vicki_(Shadi)
Found Date: 07 Nov 2014
Guessing minutes URL: http://www.w3.org/2014/11/07-eo-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]