Education and Outreach Working Group Teleconference — 14 Nov 2014

See also: IRC log


Shawn, PaulSchantz, Andrew, Helle, Sylvie, EricE, Jan, kevin, AnnaBelle, Lydia, Shadi, paulschantz, helle, Sharron
Vicki, Jon, Wayne


<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

<yatil> https://www.w3.org/WAI/EO/wiki/Evaluation_tools/Comments#Comments_to_discuss_for_November_14th.2C_2014

Eval Tools List

Accessibility/ATAG/WCAG status of the tools

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

Allowing people to add filter criteria

<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

high-level issue of number of filters

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

Intro issues

<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?

Wording/Styling for results status

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

Summary of Action Items

[End of minutes]

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