See also: IRC log
<trackbot> Date: 14 November 2014
<scribe> Scribe: Kevin
shawn: Excited to welcome a new participant
<shawn> [introductions]
Lydia: Work for A&M
University, involved with EIR.
... Been involved with accessibility and online courses for
over 10 years.
... EIR = Electronic Information Resources
shawn: Reminder for those not
comfortable with GitHub, you can still use the wiki
... Would be good to try to work more with GitHub as we move
forward
eric: We should have filter
criteria on which tools are WCAG or ATAG
... We would need to collect this information, and
... we would need to somehow verify any claims
Sharron: Could the burden of
proof be moved to the vendor by phrasing the question as 'Does
this tool claim...'
... Would that solve the verify problem?
shawn: That is one possible solution and we do state that we don't verify the information
shadi: All the information is
provided by tool vendors and we don't verify any other
information.
... If we are collecting this information we would also need to
think about how it fits into the structure.
<Andrew> +1 to Shadi
<paulschantz> +1 to Shadi
shadi: Would also need to think about other guidelines such as UAAG. Might be worth asking the question simply as, 'Is this tool accessible?'
shawn: Any concerns with not verifying?
eric: I do have a problem as this
is quite a bold statement to make to simply ask 'is this tool
accessible'
... I think it would be better to not have any claims
shawn: As Wayne points out, many tools don't work for him so he doesn't try them.
<Sharron> Sharron: I think asking "Does this tool conform to W3C standards." Then provide checkboxes for ones that are claimed
<Sharron> ...and links to their statements about conformance
Jan: Is there a way for people to comment on claims privately to W3C?
Shawn: This would be difficult again from a resources perspective
Shadi: Unfortunately this would
raise a need for verification of the complaint as well as the
original claim
... This issue applies to all claims that the vendor makes. As
eric points out, this is a more involved and political
claim.
... Unfortunately some tools may be unable to make their tool
accessible as they have to present inaccessible problems.
Helle: Is it possible to make filtering based on ability to access, for example, provides keyboard access
Sharron: Sensitive to the idea
that a vendor will not be comfortable saying their tool is not
accessible.
... Might be better to provide positive statements that they
can highlight such as ATAG compliant
<yatil> Usable using… [ ] Screen Reader [ ] Large Text [ ] Keyboard
Sylvie: If we add this we would
need to go back to vendors for additional information.
... Also, allowing users to comment would be good.
Shawn: Unfortunately, providing functionality for users to comment is out of scope at the moment.
<shawn> ... thanks for the idea
Andrew: It is easy for people to say ATAG or WCAG compliant and easy to poke holes in this. Eric's approach is good as it avoids this issue.
Shawn: What could be on such a
list of items?
... Screenreader
... Large text
... Keyboard only
... Colour blindness
Andrew: Screenreader compatible
Helle: Voice input
<yatil> Custom styles
<shadi> clear error messages
<shadi> text alternatives
Andrew: System or tool settings e.g. colour
<shadi> (sign language)
shadi: Would this effectively recreate WCAG as a list a be too long?
<shadi> meaningful sequence
<shadi> use of color
shawn: What is the negative of using the guidelines as a question e.g. Does this tool meet ...?
Andrew: It might meet all but one criteria but is still usable by many many people
shadi: Vendors try to tick
everything they can to make their tool look good
... People who are more critical of their own tool, may be
disadvantaged
... Would also need to clarify that the question only applies
to the tool itself not the content that it might generates.
<paulschantz> you really think vendors will game the filters?
<paulschantz> there are more filter options than tools in the list
eric: The problem with having
WCAG 2 etc in the filters makes it look very official
... Might be better to ask for a link to the Tool Conformance
Claim
shawn: How many Vendors are likely to have that?
Andrew: Not likely to be too many especially for shareware, open source etc
shawn: A comment field might help those where there are only a few non-conforming items
<Sharron> Starting to move toward the idea of a check box of some high level, broad accessiiblity issues and allowing checking off for keyboard access, text resize, contrast...things that produce severe barriers
<Zakim> Andrew, you wanted to ask sylvie what might be most useful
shawn: Use case... say I am blind and I want to check luminosity contrast ratio. In this case many of the tools are likely to be unusable due to the nature of the issue. But I would like to try to find something to help me
Andrew: Sylvie, is it better to say 'works with a keyboard, etc' or to say 'WCAG compliant'?
Sylvie: Shawn, I use the a tool which tells you textually what the luminosity ratio
shadi: There is a category called 'Features' (previously 'Assistance'), this could be used to highlight how the tool supports alternative access options
Sylvie: Two points regarding accessible information; is the tool accessible and is the report accessible?
paulschantz: How many tools are likely to end here?
shadi: 100+
paulschantz: Currently there are
more filter options that tool entries. Are we focusing on this
a bit too much at the moment?
... It was just as involved for me to scan the list of tools as
to scan the filters
<paulschantz> If it wasn't clear, I like that we have filters here
shawn: Where are we on the big
picture of responding to users need to filter by some sort of
tool accessibility or find out more about the accessibility of
the tool?
... Another option is to encourage vendors to provide
information on the accessibility of the tool without providing
a filter.
<shadi> +1 "(optional) provide a link to information about the accessibility of your tool"
<AnnaBelle> neutral
<Sharron> +1 "(optional) provide a link to information about the accessibility of your tool"
<Sharron> ...and should include filter so people who need it will find it
Jan: I like having a filter, still think that if vendors are making claims they would need to provide contact info for people to ask about their claims.
Sylvie: How can you find if a vendor has included accessibility information if there is no ability to filter?
<Sharron> +1 to filtering for that info
<yatil> Likes Sylvies idea and +1 "(optional) provide a link to information about the accessibility of your tool"
<Helle> +1 sylvie
Proposed solution: Optional field that vendors could provide either a link to tool accessibility information or comment on the tools accessibility information
<paulschantz> +1 to adding link to vendor accessibility statement
shadi: Link is easier to present and check. It is also more elegant as it encourages vendors to create this information without any sense of enforcement
yatil: Link to a basic accessibility information with a filter would be good
<shawn> https://github.com/w3c/wai-eval-tools/issues/15
<Sharron> -1
eric: This creates a need for moderating what people are suggesting to check if the added option makes sense or might fit better elsewhere.
<Zakim> shawn, you wanted to ask about listing the info in their details w/o adding a category in the filters
eric: Considering removing 'Other' field but that means that we might miss useful categories
<Andrew> enter a tool - http://www.w3.org/WAI/ER/tools/submission.php
<Sharron> +1
shawn: What about providing the vendor with the option of adding additional information that would not become a new filter criteria
eric: One problem is that this can lead to long tool descriptions which we already limit
shawn: What if I could type something in 'Other', it doesn't become a new filter category, but would still be listed in my details?
<Andrew> ditto e.g. for Browser plugin for ... would allow every version or combinationt o eventually be added
Sharron: I like this as it allows you to keep the descriptions short, but doesn't limit users in adding clear information about their tool.
shadi: This was originally added
to capture languages and guidelines. There are times where we
will want to add new categories.
... There is some level of moderation and monitoring that is
required
Sharron: The language category makes sense to capture this. For other categories my assumption was that the resources weren't available. If this is moderated then this is fine... self-moderated is not.
shadi: 'Other' makes some sense for some categories but not for others
<Zakim> kevin, you wanted to suggest a specific field to request additions
Andrew: Agreed
<Andrew> Kevin: while we do wnat to capure some of his info, we don't wnat to autoatically add it all to new categories
<Andrew> ... if we allowed text for other, then could review periodically for additions
shawn: Seems to be uniform
agreement to automatically adding items added into
'Other'
... Somethings need 'Other' more than others e.g.
Language
... Somethings really shouldn't have 'Other' at all
... Wishlist for future enhance is that 'Other' could become a
comment in tool details
shadi: Should we discuss Paul's earlier comment regarding filter categories as that is pertinent
shawn: Expectation is that we
will have up to 200 tools
... Shadi, what are your initial thoughts on Paul's
comment?
shadi: There was a lot of
analysis on what filters should be included.
... It could be that there are items that are less than useful
now but it is a non-trivial exercise to review these.
shawn: Any thoughts on which filters are useful or not?
kevin: Drop 'Provides APIs for'?
paulschantz: I think that people
who are going to come here for specific tools they will need
the guidelines certainly.
... I agree that we should probably get rid of most of the
filters
... Might be feasible to hide them more thoroughly
<shadi> [[maybe items with 10+ tools (except for guidelines, languages, and licenses)
paulschantz: Keep: guidelines, languages
<Zakim> Andrew, you wanted to suggest combining some
paulschantz: Drop: Runtime, APIs, Online service
<shadi> [[think that "online" and "assistance" could be combined]]
Andrew: Type of tool could be
online service, browser tool, etc.,
... could condense Type of tool into one item
shawn: More discussion or do you want to come back with a proposal?
shadi: We have some direction and
even the submissions provide us with some indication.
... Maybe we can capture but not include filters, or hide the
filters more.
<yatil> Filter: Type: [ ] Desktop [ ] PlugIn [ ] Server Side
shadi: We will look at design ideas and bring back to EO
<Andrew> should keep most of License Type too
Shawn: Can include 'Other' as part of this design review?
eric: If we narrow down filter criteria, then we can think about which ones would benefit from closer moderation
<shawn> https://w3c.github.io/wai-eval-tools/
<shawn> current wording: Web accessibility evaluation tools are software programs or online services that help you determine if web content meets accessibility guidelines. While web accessibility evaluation tools can significantly reduce the time and effort to evaluate websites, no tool can automatically determine the accessibility of websites. Submit an evaluation tool to the list.
<shawn> proposed rewording:
<yatil> Web accessibility evaluation tools are software programs or online services that help you determine if web content meets accessibility guidelines. While web accessibility evaluation tools can significantly reduce the time and effort to evaluate websites, no tool can automatically determine the accessibility of websites. This page provides a list of evaluation tools that you can filter to find ones that match your particular needs. [Selecting web accessibility
<yatil> evaluation tools] provides more background and information.
<yatil> https://github.com/w3c/wai-eval-tools/issues/20
eric: Current wording explains tools, Shadi suggests that the intro should explain a bit about the tool
<yatil> -> Would link to http://www.w3.org/WAI/eval/selectingtools
eric: Think that this might be a bit of a long introduction, although shadi is also suggesting removing 'While web accessibility evaluation tools... ' sentence which might alleviate this problem.
<yatil> Provide a brief explanation of what this page is about - consider such rewording: "Web accessibility evaluation tools are software programs or online services that help you determine if web content meets accessibility guidelines. This page provides a list of evaluation tools that you can filter to find ones that match your particular needs. Selecting web accessibility evaluation tools provides more background and information.
shawn: Any comments on eric's proposal above?
Sharron: Can we add a sentence around 'Human judgement will still be needed'? Current intro does not include this.
shadi: I am opting to have as
little text on the tools page as possible, and should link to
the Selecting Tools document
... which should have more of the background, including
framings regarding human judgement
<Andrew> +1
shawn: Proposal is to keep tools list focused on tools list with link to Selecting document should include all background information.
andrew: Only concern is when we will update the Selecting Tools document
shawn: Aim will be to do that soon
shadi: The Selecting Tools can become a gateway or overview pages
eric: Link to web content definition was introduced last week, but I am not sure if this should be kept
shawn: Originally this said
websites but the discussion highlighted that this could include
a lot of other items such as apps, pages, content etc.
... One possibility would be to change the visual
representation of the link to look more like a definition
link?
... Another is to remove the link altogether
shadi: I think the link as it is now as the very first link is prominent and distracting. Users may not appreciate why it is highlighted.
<Andrew> suggest remove link and instead say ''web content and applications'' for clarity
shadi: I can live with the idea of toning down the presentation of the link but would prefer to just keep 'web content' unlinked
NotShawn: If I want to evaluate 'web application' and see 'web content' would I think is not applicable
Andrew: A lot of people don't
associate 'applications' with 'web content'
... Would be happy to drop the link but not comfortable with
changing the styling
... Would suggest 'web content and applications'
shadi: We are discussing two
issues: making it relevant to application developers and the
providing the link.
... I think these are separate. I don't think the link will
help address the first issue.
... We could reopen as to whether to add in the word
'application' or not. Although I don't think it is that
useful
<yatil> “web content, such as web sites and applications,”?
shadi: I think people will just start to use filters or read list even if they are thinking 'applications'
<shadi> "web content including application"
Andrew: When Australia introduced the NTS for WCAG 2.0 adoption and were talking about websites, most agencies didn't think their application were in scope. They associated websites and content with 'static' not dynamic interactive.
shawn: For now, I would like to say the tentative solution is to go with the most simple solution which is to leave web content and remove the link. We can revisit this though.
<yatil> +1
eric: Currently we have submission link to the left at the end of the intro. Suggestion is to move it to a new line but I think it will take up more space.
shawn: Is the link required at the top at all?
eric: I like that it shows we are taking submissions
shawn: What if we changed the text to be something more narrative?
shadi: Yes
<yatil> https://github.com/w3c/wai-eval-tools/issues/21
<yatil> Wording for the submit button(s) issue: https://github.com/w3c/wai-eval-tools/issues/23
shadi: Primary audience is searchers for tools, secondary audience are vendors who are supported by the lower link
shawn: Need to check with EO; should we have this link at the top at all?
shawn: Has this been changed yet?
eric: I have changed the
wording
... The other proposal was to style the matched filters
differently (can be seen by activating a filter and then the
filters are listed below 'Results')
shadi: Suggesting adding a little bit of highlighting on each matched filter to make them stand out a little bit
eric: I am concerned this might draw too much attention to the top of the list
shawn: It would be good to get
more input from the group on this
... If everyone could note that the work for this week:
... Developing Policies
... We will create a list of open items on the tools list
... Thanks everyone