Accessibility Education and Outreach Working Group (EOWG) Teleconference -- 16 Sep 2022

<krisanne> chair: krisanne

<scribe> scribe: dmontalvo

Evaluation Tools List

KA: Some issues to discuss based on the agenda

#63 Scope of browser fields

KA: This is basically questioning whether or not we should have separate lists for online tools and for tools that run on a browser extension
... You may fill in the form differently depending on interpretation
... We may want to have this separation clearer between online tool and/or browser extension
... Thoughts?
... Personally, I want to make sure people find what they need

Laura: I think it's two different versions of the same tool. I don't think we should be list each of them twice

<kevin> +1 to not listing twice

<CarlosD> +1

Laura: At the Library of Congress we have the same content that is delivered in two different ways

Shawn: IF the online version does things differently than the browser extension that is an issue

<Zakim> shawn, you wanted to mention not fit the form

Carlos: If the issue was what Shawn described I would probably have submitted two different tools even if they are just under the same brand
... But I would not clasify them as two different tools, but as different ways of running the accessibility testing engine
... I can run it through the command line, through the website, or through an extension and it would provide the same results in different formats depending on the chosen platform

Shawn: You had trouble filling in the form, right?

Carlos: Yes, it was the questoin about the browser what confused me
... my tool works on all browsers when online, but just have one extension for Chrome

KA: The question is then if we should add additional information to help distinguish

Kevin: I get the challenge but I don't know how common it is
... One way to deal with this is letting people figure this out themselves
... We could ask for some specific about browser requirements or
... I don't think we should ask people to put two separate tools

KA: Is that something, Carlos, that you could clarify under the features?

Carlos: We could. But I remember we entered the information and I indicated for the extension that it was a Chrome extension. I do hope it is explicit from the features, but still the question remains as to what to pick on the "browser" filter
... If I just pick Chrome, people won't find the other tools
... I think I should check everything where it should work and then use the features to clariy that the extension only works for Chrome

Kevin: If it is an online tool it's likely to work in every browser
... IF it is a browser plugin we need to specify which browser the plugin works for

Carlos: That makes sense, but it would need to be explicit on the field

Shawn: I think that's both a UI and programming challenging feature
... I think that's nice to have

Eric: I had a look at how to repair this but it gets really complicated
... It is like working on a tree with many branches

KA: Combinations could be endless

Eric: At the moment our conclusion was that inputing it twice would be better

<Zakim> shawn, you wanted to say 1. eval tools not all. 2. just the one issue

Shawn: This is not the end all be all. People may need to do more research anyway
... I think we are coming to the position that you only list the tool once and you could check the most boxes that are relevant and you then should put clarifying information on the features
... I think that's where we are getting at
... But Kevin's point was different.
... Let's say I have a browser plugin. In that case you really want to know what browser it applies to
... IF the tool runs on a website, it is not needed which browser it works for
... Maybe you want to open an issue Kevin for us to record these thoughts

Kevin: I could. Kind of changing it to @Which browser this plugin is designed for"

Eric: I can imagine if you choose one thing, then you could have separate questoins based on that. But we don't have this currently like that

Brent: If I think about the use cas of someone , if I am looking for something that works for Chrome then it will show up, if I look for Firefox then it should notusing the filter
... IF I select an online it will show up
... I don't see the point of getting into that level of detail
... Do you even need browser plugin as a type of tool when you already have a browser filter?
... Is it that the tool does a specific thing differently when it is a plugin?

Kevin: I think we are overthinking this. This is for pointing people in the right direction
... We are assuming a level of intelligence applied from the user's perspective

<Brent> I agree that we are overthinking this. I think the existing selections are sufficient as is.

Carlos: To Eric and Brent's comments -- When I got to the type of tool field I selected the three boxes. I still have two further fields to field: browser and operating system
... I did not have issues with the operating system
... I fully agree with what Kevin and Brent were saying
... One way to solve this would be just to make it explicitly by having "browser plugin" or something
... But I think we could very well leave without filters for browser and operating systems, and then we specify that info in the description

Eric: Browser and operating systems are not required, we probably expected this discussion
... We could add something to browsers to make it clearer, not sure if it will cover all instances
... That addition would be an easy fix

Carlos Browser only makes sense for the plugin and for the online tool

Shawn: Plugin browser

<krisanne> Daniel: my understanding is that browser plugin could check the current page even if its behind a firewall.

<scribe> scribe: dmontalvo

Eric: Can we close this discussion by changing "browsers" to "browser for plugins"?

Shawn: CArlos, does that satisfy your use case?

Carlos: Yes if it also applies to the filters in the list, not just the summission form

#68 Renaming "features"

KA: There is now a field that is called "features".
... One suggestion was to make it bigger so that peiple knows it can hold long pieces of information
... Another suggestion was to change the label to "description" so that people know that this is to describe your tool in detail

Eric: We chose "features" because we wanted people to list key features. We did not want really large pieces of text
... If you see some of the list items they are already sufficiently long

KA: What if we clarify tosomething like "Short descriptions"

Shawn: You can put a word limit

Michelle: I wondered how me typing the feature will be different from the other filters. What would I add in these fields?
... Also if I fill in all of these in detail and then I am required to go through all the other check boxes in addition, I would be upset
... Maybe putting the filters at the end and not making them require would help with dynamics

Kevin: I get the initial rationale for taking this approach but I wonder whether actually "product description" potentially with a word limit is the way to go
... I can find few that have added a product feature, most are putting merely tool descriptions

<Brent> +1 to

Eric: To Carlos comment, we copied the existing fields from the existing tool

<Brent> "Product Description" with word limit

Eric: I am happy to change it to "short product description" and putting it at the bottom of the page. And also add a word limit

Michelle: "Product descriptions" makes sense to be first. First the overview and then the details
... I would take out the add features functionality

Daniel: Good point, that component has currently accessibility issues

RESOLUTION: Changed "features" to "product description", make the box bigger, add a character limit, and remove the "Add filters" component

<Michele> +1

<Laura> +1

<kevin> +1

<evelleman_> +1

<krisanne> +1

<Leticia> +1

<CarlosD> +1

Brent: Do we wnat to give the team an idea on what the limit should be?

Eric: Will set to 350

Kevin: Maybe use the "lorem itsum" thing for people to have an idea of how it would look like

Daniel: We should put the limit on the label as well

<Brent> +1

<shawn> +1

RESOLUTION: Try 350 but editor's discretion to go lower

<Brent> +1

<evelleman_> +1

<shawn> +1

<CarlosD> +1

Adding EN301549 to the guidelines and standards choice?

KA: This is very similar to WCAG 2.1, but we also list Section 508 which is basically WCAG 2.0

KEvin: I think Section 508 makes sense because it is well recognized
... WCAG is much more common but EN301549 is not so much
... IF it makes sense for Europe it would make sense

<kevin> ack

Eric: I think this is the same with Section 508
... To be honest EN301549 is identical to Section 508 with the requirements
... EN301549 is the standard in Europe
... We have other standards in the list as well

<CarlosD> +1 to adding the EN

<kevin> +1 to adding EN301549

<evelleman_> +1

<krisanne> Daniel: I would be suprised if its not there. The reporting done in Europe has to be done on EN301549.

Daniel: I think the reporting that you have to do in Europe is based on EN301549 so would support keeping it

<Zakim> shawn, you wanted to ask about those standards

Shawn: +1 for EN301549 and +1 for considering the previous discussion on that list
... I know we discussed this and thought we decided to take some of these out
... We should make a clear pointer to that discussion so that the rationale is clear to everybody
... Do you want to discuss this now?

Eric: No, let's find the previous discussion
... Some ountries refer both to their local standardrs and to EN301549

[[Pause to find the previous discussion]]

<shawn> https://www.w3.org/2022/07/15-eo-minutes#t02

Shawn: I think we talked about excluding some of the others, not aboutexcluding EN301549
... But it seems there is not a clear pointer

KA: The purpose of this list is which tools chek which standards
... These all have numbers
... Are people checking them because they think their tool checks everything?
... Nubers do not coincide, so there might be a reason for that

Kevin: I don't think some of the tools listed here check all the standards
... Probably they think they check them all but details are to be found out as to whether they actually do it
... For the French, Irish, German... Presumably these would be overwritten by European legislation
... EN301549 should be transposed to national legislation at some point

Eric: Yes, probably the only reason why they are still here is for backwards compatibility with existing tool

Shawn: Everyone is going to have to resubmit

Eric: We could leave them here and take it out of the submission

Shawn: I'd delete them from both

Eric: If everybody +1 that I'll do it
... Ask Vera to check the SI

RESOLUTION: Remove RGAA BITV, Irish National IT Accessibility Guidelines, Stanca ACT

<evelleman_> +1

<krisanne> +1

<Laura> +1

<Leticia> +1

Daniel: +1

<Brent> +1

<kevin> +1

<shawn> +1

<CarlosD> +1

RESOLUTION: Add EN301549 standard

<krisanne> +1

<evelleman_> +1

<Laura> +1

<Leticia> +1

Daniel: +1

<Brent> +1

<CarlosD> +1

<shawn> +1

<kevin> +1

Pagination in the Resource

KA: Do we want to have pagination? If so, how do we want that to be listed?
... Do we want to havehave all the tools listed and then filter afterwards?
... HAving a way to get the whole list is helpful for trying to find what you are looking for

Shawn: Existing tools lists have 167 tools and we think the new one will have less

Eric: Currently 156 and probably less

Shawn: The old one currently loads everything

Eric: I think they did it based on user research

Kevin: If you look at the top you don't realize that there is pagination
... 156 on one page does not seem to be many

Shawn: The current page does not have pagination, that's a reason for not having it here
... Page load times can be a problem but it seems not in this case
... Could we justify us stop using pagination?

Eric: I think taking the pagination out would be easy, I will ask them anyway

KA: I think it makes sense
... We have to adjust the wording and/or get them a quicker way to go where they want to go. For example, a quick way to go to the end of the alphabet

<kevin> +1 to paging through problem

RESOLUTION: Remove pagination or editors bring the issue back for discussion keeping it

<evelleman_> +1

Daniel: +1

<CarlosD> +1

<Leticia> +1

<kevin> +1

<krisanne> +1

<Brent> +1

<shawn> +1

<Laura> +1

<Michele> +1

Eric: We have other issues that we are working on repairing. These were the most important ones to discuss

KA: Thank you everybody for the reviews and the thank you to the team for the work

WCAG Redesign Discussion of In Progress Prototypes

Shawn: We tried to et this done before TPAC but we could not. WE have now more time to comment
... Not everything is done on the preview. Just on one page for review
... We need to gather all our input by next week
... I'd like to show you where we are, see if ther is initial input
... and make sure everything we know of is either already done or listed as an issue
... Please have a look at this in the next couple of days so that we can have a discussion next Friday

<shawn> https://deploy-preview-35--wai-wcag-redesign.netlify.app/

Shawn: From the agenda there is a link to the prototypes

<shawn> list of what to look at and known issues https://github.com/w3c/wcag-redesign/pull/35

Shawn: In the previous meeting we discussed for the techniques not to have the navigation bar
... We had made that decission, now you can see it in some places. Any initial feedback? Questions?

KA: This was done because for the techniques people felt it was not needed

Laura: It appears that the navigation is not really responsive. The page contents right-hand navigation shows up first on mobile, not sure if we want to put it at the bottom

Shawn: The second thing we want it at the top, that's something we worked with ARIA

Laura: The light blue navigation does not appear to be responsive

Shawn: We copied the decission from the tools list to have a horizontal scrollbar
... We did fix that, maybe this version doesn't have it

Kevin: Ff you go to 1.2.4 Captions (Live) you do get an example of what currently does not work
... I don't think this works

Laura: I am not convinced either

Michelle: This does not feel OK to me

KA: Was it decided in ARIA to do this?

Shawn: APG does the same thing
... That's currently implemented in the ATAG, ACT, APG, Supplemental Guidance, and other places
... For this project I propose we don't hold it up and we can list this as an overall WAI website issue
... I would be interested on your input, given that has been widely implemented for more than a year now

Laura: It's the first time I see this

KA: I haven't noticed that either

Shawn: That's because you don't see this as quickly, content in that bar is not that much in other places

Kevin: You just would not catch it unless you narrow the window and increase the zoom

Shawn: That comes actually from the first iteration of the ATAG Report Tools redesign

Laura: Even the example without the long navigation, when I decrease my browser window, the next item is still getting cut off

Shawn: Is there a scrollbar?

Laura: No.

Shawn: On mobile I get a scrollbar that I can see

Carlos: I guess that depends on the browser. I see the scroll bar after I scroll, no way to know that bar even exists

[[Screen sharing to demonstrate the issues]]

Shawn: This is a WAI website issue

Kevin: It might be good to note the Browser/OS combination for that one, it may be a browser specific issue

Carlos: It is user configurable. You can choose whether to show the scrollbar or not

Shawn: What's the default?

KA: Not to show

Laura: In my opinion it needs to be fixed anyway because if you don't have it it still is going to cut off
... You can make a dropdown or something for it to work consistently

Michelle: Should we open issues for this?

Shawn: I would prefer for us to collect feedback in wai-eo-editors@w3.org by Tuesday
... This is an editor's request

KA: We need to look at the PR but not at the issues

[[Screen sharing to qualify review items previously discussed]]

Michelle: That link took me to the nineteen issues

KA: If you have comments, please send them to the editors list that is in Work for This Week section

Work for This Week

KA: We have got the video scripts stories of web users survey that is due on the 26
... We still have our butterfly review survey for the curricula content author modules that closes on the 20

Daniel: We are on a tight schedule, please if you ahve some time take the time prior to the deadline

KA: Everything is listed on Work for This Week

- DRAFT -

Accessibility Education and Outreach Working Group (EOWG) Teleconference

16 Sep 2022

Attendees

Contents

Evaluation Tools List

#63 Scope of browser fields

#68 Renaming "features"

Adding EN301549 to the guidelines and standards choice?

Pagination in the Resource

WCAG Redesign Discussion of In Progress Prototypes

Work for This Week

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output