See also: IRC log
<trackbot> Date: 07 November 2014
<Sharron> Scribe: Sharron
<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
+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.
<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
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?
<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?
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
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]