Accessibility Education and Outreach Working Group (EOWG) Teleconference -- 21 Oct 2022

<Brent> Chair: Brent

<scribe> Scribe: Michele Williams

<scribe> ScribeNick: Michele

WAI staff updates

<shawn> https://www.w3.org/blog/2022/10/w3c-wai-updates-october-2022/

Shawn: Kevin White is re-joining!
... Kevin was previously on staff in prior years.
... Other news, Judy Brewer is leaving (transitioning now)
... WAI is continuing with current work and will re-evaluate roles, responsibilities, and staff going forward in light of new shifts
... Lots of vision for 2023; next few months will be to keep existing projects going smoothly...

Not too many changes in the immediate.

Shawn: Another exciting thing - trying to wrap a lot of work in December...

Look for what we can do MVP (minimum viable product). Version 1 of items will be getting published by end of year for a lot of resources.

New member intro: Sarah Lewthwaite

Brent: Sarah was part of curricula work and took us up on the offer to join EO when they work wrapped

Daniel: Thank you for joining us, Sarah

Sarah: Happy to be here. From University of Southampton in the UK. (Note: other intro in her email introduction.)

<shawn> Sarah intto https://lists.w3.org/Archives/Public/w3c-wai-eo/2022OctDec/0008.html

Sarah: Senior research fellow, will likely be sending out announcements about that to the group.

<shawn> s/Sarah into/Sarah intro

ACT (Accessibility Conformance Testing) Rules

Brent: Review the "Overview" and "About ACT Rules" pages for background
... We've been working this ACT wording into the Tools list, notably

Daniel: We've been discussing how to make ACT Rules more known to people
... Best person to do this is Wilco Fiers who has joined us today to give us background into ACT work and how it has developed

Wilco: There's a lot of work to summarize! (8 years worth)

Shawn: How can we help you create an elevator pitch?

Wilco: I'm the Task Force facilitator of ACT, PM for WCAG 3, also work for Deque
... Goal of ACT is to solve the problem of different testers testing WCAG end up with different results

This is most prominent in tooling

Can be very problematic for new people trying to understand where they stand with accessibility

A few components to the work which include creating rules for accessibility testing

Automated tools have a lot of rules (or checks, etc.); what we've tried to figure out is how can you write a rule that can be part of testing methodologies...

Trusted Tester is most known

The rules are written to help people who make these tools do it in a consistent way

<Wilco> https://www.w3.org/TR/act-rules-format/

As part of that, we have written the ACT rules format

It's W3C recommendation we developed with a number of testers and tool vendors

We want everyone to be able to implement them

One finding - rules need to be unambiguous (and we define that as not able to be interpreted more than 1 way)

Most rules are for HTML, CSS, ARIA, not PDF

For every rule, we've created test cases; most have 10-20, up to 30 test cases

They help determine whether a person has implemented the rule as we intended

<shawn> background from agenda: 1. ACT Overview (originally was about the ACT Rules format, and now has some added about the ACT Rules themselves) https://www.w3.org/WAI/standards-guidelines/act/ 2. About ACT Rules (the main page for ACT Rules themselves) https://www.w3.org/WAI/standards-guidelines/act/rules/about/

All the key things a tester should look at have a test case so we can confirm a tool or tester has considered it the way we intended

Shawn: EO, we're being asked to help introduce this in 1 sentence in the Submission Form

Also, to help craft an approx. 3-sentence intro for the primary page

Given that, what questions do you have and what would you want to explain to people who are accessibility aware but not advanced?

Michele: Clarification: Asking for language for lay people but this doesn't sound like it's for lay people?

Shawn: We need to help people know if they stumble upon this what this is in case they aren't the audience

Wilco: The rules themselves and details are for people writing methods, rules testers, and advanced testers

They also help as reference for what tools are doing and why they get certain results

<Wilco> https://www.w3.org/WAI/standards-guidelines/act/rules/

Especially in Europe where they are monitoring accessibility, these help to explain how consistent tools are in monitoring for that

<Wilco> https://www.w3.org/WAI/standards-guidelines/act/implementations/

Links are to the rules and current implementors that we know of

They like how many rules an implementation has (that we know of) and links to report with more details about what the implementations are consistent with

Daniel: Stepping back even more, there's 3 main aspects to consider...

The rules focus on a given set of accessibility problems; 2; they try to address problems and solutions, provide examples (test cases), and how it relates to the requirement

So less difference between your implementation and these rules, the more consistent (and vice versa)

<Zakim> kevin, you wanted to ask if it is appropriate to include a disclamer of ‘this doesn’t cover everything’?

Kevin: If we're looking to explain what ACT Rules are, there needs to be something that says "this doesn't cover everything in WCAG" - at least until it does

Don't want continued misunderstanding that tools are checking for all of WCAG

May not be in "Submit a Tool" section but might be in the main page content

Shawn: Comfortable with that suggestion and adding a GitHub for it?

Wilco: I think it's already there

Daniel: Agree, we have mention of subset

<Zakim> shawn, you wanted to move to looking at draft https://deploy-preview-79--wai-evaluation-tools-list.netlify.app/list-of-evaluation-tools/submit-a-tool

Wilco: Can likely be more explicit though

ACT Rules in Eval Tools Submission Form

<dmontalvo> https://github.com/w3c/wai-evaluation-tools-list/pull/79

Shawn: We want to educate tool vendors who don't know about ACT Rules here

We want to use this as a way to educate them about ACT Rules as well as implement them and even get involved

<dmontalvo> https://github.com/w3c/wai-evaluation-tools-list/pull/75

<shawn> ACT Rules (URL)

<shawn> https://www.w3.org/WAI/standards-guidelines/act/implementations/

<shawn> Accessibility Conformance Testing (ACT) rule implementations show how specific accessibility test tools and methodologies interpret ACT rule tesst cases. Tools that have a documented implementation of Accessibility Conformance Testing (ACT) Rules can include a link to their ACT implementation report. Users will be able to filter based on whether or not a tool has implemented ACT rules. To learn

<shawn> more about ACT implementations, read ACT Rules Implementation in Test Tools and Methodologies and Add a Test Tool or Methodology

Open up for discussion on the text on this page about ACT Rules (above)

Kris Anne: It's now in moved up the page into more General Information

Brent: "Tesst" has extra "s" and need consistency in capitalizing "rules" - sometimes it is, sometimes it isn't

Shawn: Michele mentioned how this isn't for most people, but in this case this includes the target audience often

May be some tools like for color contrast that may not apply, but overall this page will have tool vendors visiting

Now imagine that tool vendor submitting on this page doesn't know about ACT

What would be the wording for that?

Shawn: Propose a processing break for a moment then back to queue

Jade: I would break this up into 4 sentences; difficult to read as 1 paragraph; seems to be 4 points and would split them up, especially with repeating ACT phrase

Daniel: Wasn't sure if we could do that since it's a tooltip, but will have a look

Jade: May also just be an easier way to say the sentences, like "if your tool has an ACT Rules Implementation Report, you can provide a link"

Daniel: Yes, we can shorten, but there's technical reasons for some wording. Will need Wilco's input on removing "documented implementation".

Wilco: Use "documented implemented" because we won't know if they are implementing ACT rules unless they publish this somewhere

Shawn: Good enough to say "have ACT Rules implementation report"?

Wilco: Sure

<Zakim> Brent, you wanted to say "Users will be able to filter based on whether or not a tool has implemented ACT rules. "

Shawn: We are about simplification in EO!

Brent: Third sentence about filtering - isn't it they can filter if a tool has an implementation report, not just implemented the rules?

Kris Anne: Yes, and thought that should be part of the form but by the time the list gets populated the filter will be there

Daniel: Propose removing the third sentence

<shawn> scribe+

<shawn> Michele: This defines itself by itself. Needs definition/explanation of ACT Rules.

<shawn> ... missing the one-senetncve explanation ... ACT Rules provide common ways to evaluate WCAG

Daniel: That's a good point to step back

<shawn> .. first define ACT Rules. then you can say: if you don't know this, go here. If you do have the report, you can put the link in the field

Was playing with "They provide a set of pass/fail based on common accessibility problems"

<dmontalvo> ACT rules provide a set of passed, failed, and inapplicable examples based on common accessibility problems.

Shawn: That's more detail than we need; e.g., Michele said: "ACT Rules are common ways to evaluate WCAG"

Daniel: That might create problems, it's based on their set of examples and whether they pass/fail

<Zakim> kevin, you wanted to suggest ACT rules are …. They can help you by …. You can find out more …. If your tool already implements ACT rules you could submit it as an

Kevin: Was expecting "ACT Rules are..." then "how they help" then "if you have or if you want to implement"

If people already know about it, don't need more; if they don't, put a link

Keep it more straightforward and walk people through what they need to know with clear call to action at the end

Laura: Agree with Michele and Kevin, I'm really confused

Read they are informational and they're a way for tools developers to test...

but are they required to submit? Seems no, but maybe it's better if you do?

Not sure why it's included here and seems we should explain that.

If it's not required, not sure why it's on this form.

Agree it needs to include what they are and then something about why are people using the rules

However, also explain it's not required to say your product is accessible

Shawn: Clarify that it's not about the tool itself but what the tool tests

Do you have enough to take back to your group?

Wilco: Was hoping for more suggestions

ACT Rules are if you know, you know type thing

Laura: I don't get from the paragraph do I need to do this or is just more information about the accessibility of the tool?

<Zakim> shawn, you wanted to as if people know about it, they will just put their URI in there and we don't need to say that

Kevin: Maybe me, Daniel, and Wilco can talk offline more

Shawn: If it's someone who already has an implementation report and we ask for the URL they'll know what to do, right?

Wilco: Yes

<dmontalvo> Impleementation report sentence not neeeded.

Shawn: So don't need sentence since we have start of URL in there. The purpose of this is then for people who don't know what this is.

Daniel: To clarify, it's not about the accessibility of the tool itself but how its testingcompared to the rules. Will take Kevin up on his offer to talk more after the meeting.

Authoring Tools List

Shawn: Background - worked on this last year, parallel with Evaluation Tools and Course list

Want to encourage authoring tools to make their tools accessible and follow ATAG (Authoring Tool Accessibility Guidelines)

So have a list where they can share their status for users of the tool list to search and evaluate

<shawn> requirements analysis https://github.com/w3c/wai-authoring-tools-list/wiki/Requirements-Analysis:-Authoring-Tools-List

<shawn> draft authoring tools list https://wai-authoring-tools-list.netlify.app/authoring-tools-list/

Shawn: To clarify this work - The purpose of the authoring tools list is to be able to find tools that are accessible; for people who create tools, the goal is to encourage them to create accessible tools
... Steve Lee has gone through our previous EO comments and trying to get the first iteration published by the end of this year

He's suggested that many of the open issues be for the next version, and didn't see anything that needed immediate discussion

Recall that when we're close to publishing we ask you to prioritize the feedback

So, if you can have that mindset, review the Draft Authoring Tools List and see if there are any critical issues we want flagged before publishing

You can document anything non-critical as well, but overall want to know if we're comfortable with this version publishing

<slewth2___> +q

There will also be a survey, this is the initial introduction/refresher

Steve is also planning to reuse design items Leticia used for the course list

Sarah: When tools are listed, is there a date associated with them? Tools may change over time for instance. Is there a mechanism to monitor that?

Shawn: In the course list we have that [reviews it...]

Kris Anne: It's in "About this Tool"

Kris Anne: I see "date of release"

Shawn: That's not quite the same though so, Sarah, that's a good point

Sarah: Still learning GitHub so could use help getting that documented

Shawn: We can have a session after the call to show how to do it

Anything else like that? Those are the kind of things we want to catch (go Sarah!).

Would be great to give feedback by next week Wednesday; will add to Work for this Week

Brent: For both the list and submission form?

Shawn: Yes

We'll likely go to Monkey Review after this so need to know any major issues now, otherwise will open the Monkey review on the 28th

ATAG Industry Specific Briefs

Brent: Sent in the agenda and today want to get a shared understanding of what the requirements analysis is saying

Then give opportunity to give feedback so we can get it approved and start work on it

Shawn: Currently if I'm an LMS vendor and if I look at ATAG, it's confusing and doesn't seem to apply.

So what we want is something that speaks better to vendors and developers so they understand ATAG does apply to them

We want a bridge to introduce ATAG and get them to the other resources

Brent: Not to implement ATAG, those kinds of details, just something to know if it applies to them

Hopefully had a chance to review the requirements document, any questions?

Shawn: This is different than what we were just looking at - that one was older but this one is very new and able to be updated

<shawn> https://github.com/w3c/wai-intro-atag/wiki/Authoring-Tools-Briefs-Project-Requirements-Analysis

<shawn> ATAG

Brent: Want to create 3 different briefs on "Education", "Publishing", "Social Media"

Michele: I realize now I was confusing the different requirements documents (Tools list vs. this Briefs doc)

Group is going to rename them a bit

Jade: We're mentioning "social media"; do we have an accessible social media guide anywhere else?

Shawn: No

Jade: Is it too random then to have just this mention without another page for reference?

Shawn: This is calling out social media tools to say go to ATAG.

Kris Anne: Let me try to clarify: These briefs are a precursor, there are no additional guides like for education and publishing also...

but these are saying "ATAG is important for social media"...

a how to guide for social media is a possibility if asked for, but it's not in existence right now...

more it's about flagging those teams/vendors to say ATAG in fact does apply to you.

<Zakim> shawn, you wanted to say there is an implmentation for ATAG -- and it dones't need to be specific for an industry and to say at a glance

Jade: Just thinking you probably want the basics first before having to read the full technical documentation

Shawn: There is an implementation guide for ATAG

Kris Anne: But not for social media

<dmontalvo> https://www.w3.org/TR/IMPLEMENTING-ATAG20/ -> Implementing ATAG 2.0

Shawn: Right, we would never do that. The point is to say we don't need separate guides because ATAG applies.

We might do "ATAG at a Glance" like we do for other guidelines.

<dmontalvo> https://www.w3.org/WAI/standards-guidelines/atag/

We do have "ATAG Overview" and "ATAG at a Glance" though - so maybe we should point people to that

Shawn: So that's a good point that from these briefs we would point people to Overview and At a Glance first

E.g., "The first place to go get information is the Overview. Second, review At a Glance. Third, review ATAG itself. Fourth, review Implementing ATAG 2.0 (link above)"

Kris Anne: ATAG is not undergoing any rework, right? It's dated 2015 and seems like it may be out-of-date.

Shawn: We shouldn't ignore that, should put a note acknowledging that the principles still apply.

Kris Anne: Comparing to WCAG which is constantly updating, this will be jarring, they may look for a newer version

Daniel: We might point out that these are supported in WCAG 3

Shawn: May not put that since it may not happen
... Do think the ATAG Overview should explicitly call out that despite the date, the information still applies

Daniel, let's add that

Daniel: Yes

Brent: To help the sectors, it would help to give more examples of things they should include to make their tool more accessible

Daniel: Agree we need more; I started a few but could use help adding more

Brent: Example - keyboard accessibility in Education tools

Publishing in multiple formats

Social media options to provide alt text

What other examples can we provide?

Michele: I've never read ATAG. Should the examples point back to that somehow?

Shawn: Yes. And I can give an overview. There's a Part A and Part B

Part A - Tool should be accessible for PWD can use your tool

Part B - Tool should offer features to ensure you create accessible content as based on WCAG

So if talking to a tool vendor and saying they need to meet ATAG - what examples help them understand that ATAG applies to their tool?

Brent: Thinking about ACME-LMS, should be able to say "users can navigate with keyboard alone"

Shawn: But we're talking about the people using it,not the students using the results, but the teachers using the LMS

So telling them that teachers can be blind, for instance

Brent: Like teacher who wants to upload an assessment

<slewth2___> +q

Example, if teacher is trying to build a lesson and all the links are "click here"

Sarah: Is it useful to have quotes from actual users, such as actual teachers with disabilities?

Shawn: Yes, we've talked about this. For example, in "What's New about WCAG 2.1" we had persona quotes.

Sarah: Love, helps drive the point, and reinforces that disabled people are professionals

Daniel: That's not covered in the requirements analysis so we can state that more explicitly

Shawn: Put in the "Approach" section or just start drafting it

Daniel: Yeah, we may be ready to start drafting the briefs

Shawn: LMS will be a good one to start with because of the industries our committee members work in

The group has a lot of knowledge in this area

Shawn: Imagine you're talking to LMS vendor and pointing them to this page - what would that say?

Kevin: Worth thinking about how this works on Twitter - not just the page but how do we use this content on social media?

Shawn: +1, this should have good outreach

<shawn> qq+ to reply

Brent: Seems easy to have the vendor understand the WCAG applies to the tool itself; seems harder to help them understand that the output should also be accessible and need ATAG to hold them accountable for that

<Zakim> shawn, you wanted to react to Brent to reply

Shawn: Tools shouldn't just enable accessible content but should encourage accessible content (example, encourage alt text on an image)

<shawn> Michele: Have found people don't assocaite disabled people as professionals. Some understood studwents needed accessible outsput. Howver, did not understand that teachers have disbilities that use the tools.

<slewth2___> +q

<kevin> +100 to increasing awareness about accessible work environments

Kris Anne: Agree, have had that experience that people don't understand that people who use your tool need it to be accessible

<slewth2___> -q

<Zakim> shawn, you wanted to not other resources!

Sarah: Also agree with that, that's why ATAG is so important to reiterate that people with disabilities aren't always just receiving services

Shawn: Helps that we're also creating the resources about How People with Disabilities Use the Web (updating the text and creating videos)

Jade: That may be the most useful way to situate this - start with the person then go to into ATAG

Even play with idea of a postcard...

And include what's the difference between ATAG and WCAG

<Brent> +1 to Jade

Otherwise might be too jarring to just jump into ATAG

<Laura> +1 to Jade

<krisanne> +1 to Jade

Daniel: Yes, been playing with some of this and can even more incorporate how this impacts people

<Vicki> +1 to Jade

Shawn: To clarify your earlier point, we wouldn't quote an actual person but would definitely use actual examples

Sarah: Yes, I can help get quotes we can fictionalize (can't make next meeting but can do that offline)

Jade: We might able to use some TikTok content as well; a lot of people have videos about how they use AT as well

<shawn> new issues goes here https://github.com/w3c/wai-intro-atag/issues

Work for this Week

Brent: Video script survey is open, and closes today

Request to have it open until tomorrow (Saturday)

Wanted Shadi to have the weekend but only 5 responses and some people still working

Any objection to keeping it open until tomorrow?

Kris Anne: Seems good to keep it open since there's still people working on it

Kevin: Might be helpful to point out that we're getting the video production in place

Shawn: Let's check with Shadi in case he has scheduled time on Saturday for this where this might overlap

Kris Anne: I scheduled time with COGA and Accessibility for Children to alert them the survey was closing

Kris Anne: Can also attend the Children meeting next Thursday to recap their comments

Brent: I sent a note to Shadi and will update the group accordingly
... We updated 2 additional items on the Work for this Week list including the Tools List and ATAG Briefs

Links reflect where to put comments for each topic

- DRAFT -

Accessibility Education and Outreach Working Group (EOWG) Teleconference

21 Oct 2022

Attendees

Contents

WAI staff updates

New member intro: Sarah Lewthwaite

ACT (Accessibility Conformance Testing) Rules

ACT Rules in Eval Tools Submission Form

Authoring Tools List

ATAG Industry Specific Briefs

Work for this Week

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output