Current Resource: https://www.w3.org/WAI/test-evaluate/preliminary/
Requirements doc: https://www.w3.org/WAI/EO/wiki/Easy_Checks_2022
Brent:Easy Checks is a resource many people have found useful for checking websites
We are looking to update it
Brent: If you'll focus on the "Use Cases" section of the requirements...
are there any other thoughts on draft use cases and planned users?
Howard and Brent have already commented, others can now
Howard: I use it in my class so I thought of teachers and students
Shawn: Want to say more about how it is used?
Howard: I use it to introduce
evaluation of websites. I have an assignment to have them go
through the Easy Checks on several websites.
... There's guidance on how to use it and what to focus on.
Recommendations for corrections...
I'd be able to help with suggested lessons plans for teachers...
That could describe what students do with it.
Shawn: Where you have your comment, turn that into an actual use case.
Howard: Okay
Brent: For me, thinking about my role at Pearson, if you're talking to someone who is just getting into accessibility...
there's not easier things to fix but having easier things to check is where I start people.
Brent: Having a page that shows the checks and how to do them and introduces these 10 (or however many) gets them started..
Gives them a place to start their journey. They know it's not fully conformance but it an introduction that they can build on.
Mark: From Scottish government perspective, testers and developers would use this...
they are third parties we outsource to...
but this use case would also be people who don't know about accessibility.
Mark: For instance, we can use this to help people who are at the start of the procurement process...
those people can check for accessibility themselves with something they helps them run through a few checks...
They can start to tell what's the most accessible for themselves....
People know what the Tab key and what a link is, enough to do this without having to fully know the field of accessibility.
Shawn: There's a draft use case for "Procurer". Can you see if there would be edits to that given your expertise?
Mark: Sure.
Brent: Refresh the screen - there's already a "Teacher/Educator/Learner" use case
Add comments to that section for that topic
Daniel: Another use case we have is the person who wants to advocate for accessibility but doesn't fully know the topic...
We could also make a stronger case for the following: People may not have the technical knowledge about accessiblity, for instance many people with disabilities who are experiencing an issue...
so we can make that a specific use case to aid that scenario.
Shawn: How can we incorporate that? I started a draft.
Daniel: Your start works but also we can add that each current use case persona has a disability...
This reinforces they are professionals and this is strengthening their communications about digital access.
<Zakim> shawn, you wanted to ask where Easy Checks fits in learning process (follow up with Brent's comment)
Shawn: For background, a person new to this resource took a look, and then did some usability analysis on it. Some feedback came back not only that people didn't know accessibility but also didn't know why they should do accessibliity...
Do we need to represent this explicitly in the use cases?...
For instance, should the Procurers just be treated as people who don't need to know the why but just the how to check?...
But if have a person like Brent described who is new to a11y, would there be more of a path you send them through with several resources?
Shadi: Strongly feel we should
keep things separated.
... We can just include a brief statement then point to
"Understanding" documents now that they're integrated...
rather than too much upfront information/work to get into the resource...
Some of us love background and resources but it may come out to be "big walls of text".
Which we want to avoid.
<shawn> +1 that we want to avoid content in multiple places (as previously prioritized by EOWG)
Jade: Can relate to 2 of the scenarios... do something like what Howard described with students where they explore a site...
then we have procurers who are assessing a site without my knowing until the end of the process...
<Jade> https://tetralogical.com/blog/2022/01/18/quick-accessibility-tests-anyone-can-do/
and this resource is one to look at for us in this work.
Shawn: Yes, had added that to our
list.
... Sounds like what we have in these use cases reflects real life experiences,
is that accurate? Are there any others missing?
Kris Anne: Do we want to put this as part of someone's training for accessibility professional? Is that the "Trainer" one?
Kris Anne: This would be someone starting their career, not the trainer themselves.
Sharron: People who will be professional testers wouldn't use this, it's too basic...
It's a good introduction but not part of a professional tester's training, is it?
Brent: No, it's not for testers. More for a team that has accessibility come up in their current work and they aren't familiar with the topic at all.
Sharron: Right, they don't have accessibility assessment as part of their core job but it comes up at times.
Kris Anne: It's part of an onboarding process.
Mark: If someone is a tester probably not, but sometimes I want people to do a quick regression test even after professional testing was done...
this gets good coverage for someone that is not a professional tester but needs to do a quick assessment of something.
Brent: Notably, there aren't professional accessibility testers in our current teams, the Quality Assurance teams are covering that and they're not necessarily fully trained or able to devote full focus on this...
So sometimes it is helpful to send this to a QA tester to incorporate in their testing...
They are easy to understand, easy to see how to check for them, and it will build up knowledge of the users, their needs, and how to read other criteria...
Agree it would not be for accessibility testers, they should know the full level of criteria...
However, agree with Kris Anne that maybe "Trainer" is not the right description...
Also agree with Shadi that you don't want multiple resources...
Think we need to think about is this for someone with no accessibility background versus someone who has some but just wants to test...
<Zakim> shawn, you wanted to ask about Content author/designer use case someone just typed in. And to ask where Easy Checks fits in getting started learning about accessibility?
This will feed into what's the opening.
Shawn: Someone added "Content Author Designer"...?
Jade: It was me.
Shawn: Would someone check their own work? Can you explain that more?
Jade: If you're a freelancer and need to show a client what you can do, they may want to use this...
they may want to have accessibility represented in their work without being able to get fully trained up on the topic.
Laura: Agree. Not everyone has same level of understanding but often are checking your own work even in an organization.
Shawn: Can everyone look at what Jade put under "Content Author Designer" and see if there are revisions?
Laura: Looks good to me, seems to represent what's happening with authors and designers....
Coders may have more awareness but designers and writers have been skipped in the resources...
That's getting better but they don't have a lot.
Shawn: Is there more about their knowledge level?
Kris Anne: They may have no knowledge.
Laura: Many in our organization have no or little knowledge. We're trying to get people aware with campaigns in the company.
Jade: We can add "He started using..." to make it more clear.
Brent: If you have more thoughts, comment in the Wiki with your name so we can know where to follow-up if we have questions.
Brent: What accessibility
knowledge should people have before using this?
... Should we point to other sites at the start, for
instance?
... In the requirements there's a section on "Audience"...
what is our target audience's knowledge and should it state that in the opening?
Laura: The title implies that it's people with limited knowledge...
and it's a way to get introduced.
Shawn: We want to be clear on intent and then be sure we're communicating this to the readers....
and we want to clearly document that in the requirements document.
So that encourages more comments from the group - let's get it written out.
Brent: Right now the "Primary Audience" says "non-technical people with low knowledge"...
Laura: Would take out "non-technical"
Kris Anne: Often we're trying to make the case for accessibility against bad advice even among technical people.
Laura: Maybe we add both
Sharron: Agree, add both "technical and non-technical"
Shawn: Refresh to see if that's what we want to say
Kris Anne: We can then break up our use cases potentially.
Daniel: I question the knowledgeable evaluators; people may want to compare with their habits but mostly want to set expectation for a knowledgeable person.
Shawn: Maybe remove knowledgeable people as a secondary audience?
Daniel: Proposing what to do if we need to keep them. The "newbie" makes sense but I could see removing "knowledgeable" as an audience.
Kris Anne: I hear you but I think I have a scenario for knowledgeable people...
A person may be evaluating a product and before that experienced tester does an extensive test on something that someone claims is accessible...
they can use this to do a quick assessment before putting in time for a more full conformance test.
Kris Anne: Often someone just takes a vendor's word on accessibility and it turns out not true when an accessibility team member is able to run an actual test.
Daniel: Yes, I can see that one. So this could be used to showcase the potential problems. I added "for potential clients" to help...
At first it wasn't clear how they were using this but see now it's not for them to do the actual check...
but rather for communicating with others.
Brent: Other comments on background knowledge or target audience?
Shawn: Howard, since you need to leave early I wanted to get your comments.
Howard: Yeah, was exploring bookmarklets and seemed cumbersome to follow the links. Some of the links weren't active any longer...
We need to promote tools that are most common and easy to access...
There may be issues with them like accessibility so we'll want to weigh that with ease of use, etc.
Howard: I have students use WAVE and WAI Color Checker
I could provide a list of what I suggest...
Those are the ones I know of at least...
Sharron: Still feel they're useful.
Sharron: Paul J. Adams has a group of tools you can download it seems; you put it in your Bookmarks tab and can select the type of check you want.
Brent: When you click the bookmark, it checks your current page for the aspect you chose.
<shawn> examples of bookmarklets https://www.w3.org/WAI/EO/wiki/Easy_Checks_2019_Project_Plan#Bookmarklets_for_Accessibility_Evaluation
Howard: Still sounds cumbersome. I have 100s of bookmarks and if it's not set up with an easy interface that can discourage people..
People are used to working with an extension or a standalone tool.
Sharron: [Shared screen] Shows
the list of types of tests that can be run from a list of
topics like "Headings".
... If, Howard, you think that would be hard for people to use
I'm not pushing for this.
Howard: I've not used it so something to explore.
Shawn: Sounds like we need to explore some more...
If we were to go with bookmarklet approach, maybe we do a quick demo for instance.
Brent: Looking at survey results (agenda item #5), most people were in favor of it....
<Github> https://github.com/w3c/wcag-eo/issues/5: Understanding 4.1.3 Status Messages (Level AA)
but Daniel and others brought up the security issue. Some may not be able to access it.
(That is, bookmarklets may be locked down.)
Shawn: In closed environments, what are people able to do or not do? We should put that in GitHub and get feedback on that?
<Zakim> daniel-montalvo, you wanted to ask what would be the problem if we mentioned both approaches?
Brent: Agree to having data around that.
Daniel: Can we mention both
approaches?
... We can explain the differences and when each approach works
best.
Shawn: We need to decide how we're going to restructure the resource....
E.g., will there be instructions for each tool, ways to filter them?
Kris Anne: And where's the line where the resource is no longer "easy"? If they need to install, download, etc.
Brent: My view of the page is that there's an understanding of the issue, then links to tools, then what to check for, then expand/collapse for how to check with the tools they already downloaded...
so here's the tools and the checks. That's my understanding of the structure and now do we need to make changes...
For instance, does the bookmarklets change that layout?
Shawn: We don't want to do it like the current version, it's too complex...
We want something much more simple...
e.g., we might decide on bookmarklets and that's it. Or we understand the diversity of people's systems andpreferences, and we provide multiple options...
then it probably has filters based for your system at the beginning...
it's more complex but more tailored.
Brent: Much more complex to create but easier for users to use?
Shawn: Yes
Shadi: And the maintenance will
be hard and someone will have to keep doing it.
... I think we should choose 1 or 2, the ones that are the most
efficient...
Think about things like royalty-free, etc., as considerations...
but overall make it clear that we have chosen a few, link to list of "Evaluation Tools" for people to find more, and keep it simple.
<Brent> +1 to Shadi
Brent: Anything else to
add?
... No one else is chiming in and we can gather more data for
it.
Shawn: If you were tasked with mentoring a new person on accessibility, what resources do you tell them to start reading and where does Easy Checks fit in?
Shadi: What's their background?
Shawn: Let's say they never heard of it and they're a UX Designer
Laura: How much time do they have?
Shadi: And how much does accessibility play into their role?
Shawn: You aren't going to talk to them very much, this is part of self-learning and it will be part of their job
Shadi: In that case I'll send them to the course
Laura: Right, and they're not going to be doing testing
Shadi: If it's someone who needs to do a quick check of their website and wants help, I can hope to send them to the Easy Checks...
I love the Perspectives but that's a bit much. They need an overview to answer "How are we doing?...
So this will help me get this task done for now, and longer term I'll send them to other resources.
<shawn> questions:
<shawn> Detail — Level of detail we want to include in this resource, versus linking to info elsewhere:
<shawn> How much do we want to explain why the check is a barrier?
<shawn> How much do we want to explain the WCAG requirement?
<shawn> Do we want to add information about fixing each issue?
Shawn: From the usability testing, they were saying they don't understand the "why" of accessibility
Brent: In your sample scenario from earlier, I would first talk to that person about disability and the idea of an access barrier...
It's hard for someone to understand why keyboard focus is important without the context of someone navigating solely with the keyboard.
For me there would be background information I would give, though it wouldn't need to be in this resource.
Shawn: Should there be pointers at the topic to say "This resource covers X, and if you want to know Y go here."?
Brent: In my experience, as I've explained the criteria items to people, they don't prioritize doing it because they don't understand how it impacts a person..
so you introduce that then say, "Now here's how you can check for that."...
So going back to "Level of Detail", there's one about how much we want to explain the WCAG requirements...
do we want to say it without all the context and background? I'm not sure.
Shawn: We intentionally don't say "conformance", for instance. They're related to WCAG but we keep it out.
Kris Anne: I prefer to keep "conformance" out.
Sharron: And it's not what they're looking for at that time anyway. You may not even know that word yet.
Jade: Agree with Brent. Before this resource, people will need a lot of background and I'm going to paste another resource we often use for that...
It's clearly laid out and something that should come before the Easy Checks...
We also use the TetraLogical resource. Overall this needs to be scaffolded so people can iteratively try things out.
<shawn> [ Jade - we sometimes start with something easier than Easy Checks https://abilitynet.org.uk/news-blogs/everyone-can-sculpt-accessibility]
Shawn: So let's discuss even more what parts to include in the resource such as why something is a barrier.
Brent: Let's step through 1 at a time. First, let's discuss the "why"...
Do we want to go into the explanation of the issue/barrier to users before get into the check?
Sharron: I think a sentence that says why this matters is enough. We don't need a complex explanation.
Mark: I agree, can't be too long.
Shawn: Compare to what's there currently. It's more than 1 sentence currently.
<shawn> Michele: +1 to Sharron
Brent: Right now the level of background is good....
Sharron: Doesn't that contradict that we're not trying to convince them of why, just trying to tell them how?
Brent: It does
Kris Anne: I thought we were trying to say who it benefits
Sharron: I would try to be as brief as possible. My guess is people are not there for the why, they already know that.
Shawn: There's a general why and then a why for each test.
Would you make changes to that?
Sharron: I won't do it now but I
think we could shorten it.
... Reduce redundancy and link to the resources we already
have.
Shawn: Perhaps we need to say more at the beginning based on the user feedback, maybe.
What do others think?
Sharron: My opinion is more that it needs to be brief
Shawn: The user testing environment may have influenced the feedback, but if it came up perhaps it's something we address?
Brent: Looking at the Color Contrast section, it's teaching about contrast ratios and perceiving color and then the checks at the bottom...
so I agree that we can just make a simple statement about "in order to be accessible, contrast ratios need to be..." and then here's how you check...
If they want the background on who it impacts, the color differences, style sheets, etc., they can learn that somewhere else...
For this, you make the 1 sentence statement about it then get to the check to see if you're doing it accessibly.
Brent: So overall do we want this to be a teaching resource or not? Seems we're leaning towards not, just a "how to"?
Shawn: What do you need to know in order to do the check?..
For example, with contrast you just need a number. But with image alt text, you need more context to know if it's good alt...
So sometimes you need a bit more background to even do the easy check.
Sharron: Yeah
Daniel: At the end of it, this is about people having access to your site. So at the beginning we can have a 1 line that states what this does for folks...
So explain what people do with this item, like what people do with Headings.
<shawn> [ criteria for how much to say: what do they need to know to do the check. ]
Brent: What about any explanation of the WCAG Requirements?
They currently link to the requirements via the "learn more"
Any thoughts on explaining WCAG requirements? or just link to them?
Also, what about information on fixing the issue? What happens if they find an issue?
Should it link to the techniques? Or does that lead to more teaching?
Kris Anne: Issue I've seen is that you link away from the resource once you get information about how to fix an issue...
Can we have a section at the bottom rather than taking them away from it mid-resource?...
Otherwise they may not run the rest of the checks. I want to wait until the end to say, "If you found issues with these, here is how to fix them" or "here are resources to give your team"...
Then those can be the Understanding docs and other resources we have...
In the past I've been linked out of a resource in the middle and I end up going "never mind" because I can't figure out how to get back into the resource,
Brent: I like the idea of having a separate section about how to fix it all..
However, are some of the issues more complex? Do they have only 1 way or is it more complicated?...
Is it going to be straightforward on how to fix it?
But I like the idea of "Found Issues? Here's how to fix them:"
Kris Anne: Yes, like Next Steps. To me that's where how to fix should go
Whether we realize it or not, all of our resources are a progression of learning...
(Jokingly) Shadi probably already knows this and just needs to write it down.
Laura: I think there should be a reference on how to fix it but don't have specific suggestion as of yet...
Agree that some areas may need more explanation.
Because if people are just finding problems and need to go elsewhere to fix them then that's not the greatest experience.
Brent: Goes back to the purpose of the resource
Daniel: Not sure we should mention how to fix because some are not straightforward and the explanations would vary...
We should qualify that some issues are more difficult to fix
If we have a title "How to Fix" may give the wrong impression
Sharron: Agree, you'll want to be consistent based on looking at each solution. Sometimes it will make sense within the section but need to assess that.
<shawn> Michele: One thing to streamline wording - rather than a check & a fix -- provide the ideal outcome.
<shawn> ... sites need to do this. check it. Then I don't need additional text for fix.
<Zakim> Brent, you wanted to say proposal of stages
Brent: What Michele just said might negate my suggestion but what if we build the resource then do some research to see if we need to make more changes...
that is, we build this in stages...
For example, do people feel it leaves them hanging about how to fix? Something to consider
Sharron: I like the idea of usability testing and if we can have a draft by AccessU we could do it there.
<shawn> some usability testing on current resource (though some mis-match with taarget audience and use cases): https://www.w3.org/WAI/EO/wiki/Easy_Checks_analysis
Shawn: Not sure about making the
date for AccessU for this update.
... We need to tighten the scope for sure, that's why need to
set expectations upfront for the resource.
... Would love to keep usability testing redesign prototypes and AccessU will be a good place if we can.
Brent: Be mindful that Daylight Savings Time is going to impact our next couple meetings because it changes differently all over the globe.