W3C

– DRAFT –
Cognitive and Learning Disabilities Accessibility Task Force meetings

Attendees

Present
Jennie, ShawnT
Regrets
-
Chair
ShawnT
Scribe
Jennie

Meeting minutes

Jennie: I confirm that I have added the testing subgroup calendar items on the COGA calendar.

<ShawnT> https://docs.google.com/document/d/1-FPbYKghJUYvn-9UzZGkANXdYCPPAFjf?rtpof=true&authuser=shawn%40shawnthompson.ca&usp=drive_fs

Shawn: (displaying file 4.3.6 Provide Search)
… Jennie's comments did show up

(Shawn went back to discussing 4.3.6)
… Difficulty defining testing scope for terms like "Ideally" under What to Do
… Shawn reviewed the information in 4.3.6
… Shawn described the information he added in the Questions to answer - what tests are needed section

<ShawnT> https://docs.google.com/document/d/1-FPbYKghJUYvn-9UzZGkANXdYCPPAFjf

Shawn: text suggestions can be really helpful
… I put the types of tests I defined.
… Binary, user, process, automated
… I listed specific tests under each one

Jennie: does it have autocomplete is more binary (yes/no)
… Does the quality of the autocomplete improve the user's experience is a user test

Shawn: I moved it under user testing and updated the language

Shawn and Jennie talked about procedural and automated behavioral testing, reviewing the research Shawn did
… some aspects can be automated.

(John K joined the meeting)

kirkwood present+

kirkwood: Under what tests are needed is missing whether or not the search is in a consistent location
… Easy to find is hard to test
… Getting to an agreed upon definition of "easy to find"
… An industry standard location
… Where the user expects it to be
… Like top right, or top left
… What the general UX standards are for search
… For people with limited visual attention, or limited visual fied
… Having it in a consistent location based on best practice
… That is very important

Shawn: Lots within Making Content Usable is user testing
… Making sure you are including users to make sure the search is easy to find
… What's easy for me doesn't mean it is easy for you
… That's why we need users to test
… Is it easy to use is another one
… (continued reading from the user testing section, and updating the document)
… Inclusive for everyone - some things we are doing can become barriers for others
… Options is always a better thing to do, but if you give them too many it can become overwhelming
… How many features are available for the search may overwhelm some

<kirkwood> easy to find? should be is it in a consistent location on site? is it in an [industry] standard location? [something like that

https://docs.google.com/document/d/1-FPbYKghJUYvn-9UzZGkANXdYCPPAFjf/edit

(discussed John's comment in the chat)

Shawn: this is covered in 4.2.2 - common designs that are familiar to most users
… This is similar to what David F was saying - several patterns connect to each other
… I added a link to this in the document

Jennie: Do we need a document that starts to collect the overlapping tests once we have identified all tests needed?
… When possible
… We have to break down each test to its smallest level, then see where there is overlap
… We can then consider combining those that overlap into one test process when this best meets the needs of people with cognitive disabilities

Shawn: Yes. Then in "What tests are needed" section, we can add related patterns.
… (updated the document)

Jennie: Recommend updating our template after this discussion during our next planning meeting.
… And update ones we have already completed
… Example: regions on HTML are used for ARIA. Within those sections, we could validate if the search is here. Like a header region.
… We could leverage ARIA regions, used for people using screen readers.
… Having the search placed within the search "region" which could be between the header region and the main navigation region, for example
… This would make an automated test possible, if this was the "location" that was determined the best location

JohnK: There was another member previously who advocated for this. That ARIA could be leveraged for people with cognitive disabilities.

Jennie: It would help in terms of testing, could also support better navigation options if exposed to cognitive disability AT
… Yes, landmark

Shawn: On Safari, you cannot tab to links by default - only goes to form elements. You have to turn that on

JohnK: The person I referenced is Richard Schwerdtfeger

Shawn: this is used a lot by voice over users

Jennie: sorry, not landmark, it is region

Shawn: the one we use is the landmark
… head, main...those are landmark

Jennie: those are the ones I meant, thank you!

JohnK: What you are discussing brings up cognitive accessibility for the blind
… Jennie said she has heard 3 navigation areas - that can be a fail from a cognitive accessibility standpoint for someone using a screen reader
… That brings up a good issue around that, that we don't talk about it very much.
… We don't have a lot of native screen reader users in the task force.
… But it definitely should be a fail.

ShawnT: ARIA is developed for screen readers.
… If we can take it and put it somewhere else, where it would be useful
… Like cognitive disabilities
… I think Lisa was at the beginning of ARIA

JohnK: Yes, Lisa and Richard were in that group together

Shawn: Back to the search
… Using a bookmarklet for Safari, shows you the landmarks
… There is a role of search on this page
… What Jennie is saying is we have 3 navs on this page: a skip to content, the main menu, then the bread crumbs
… At the bottom of this page is 2 more navigations
… A screen reader user will be told that there are 5 navigations, but not know what those are
… There is a hidden H2 on this page
… A labelled by fixes this, and adds the name to the navigation to define which one

Shawn: What happens with an in-content search, in the main content area

JohnK: I think that is fine

Jennie: A procedural test would come into play
… Test 1a is the automated test that finds searches on the page
… Test 1b validates if the 1st search is within the 1st 3 ARIA landmarks - meaning it is in the top
… Additional searches on the page or ones not in the 1st 3 get validated manually, this is part of the procedures
… Testers could stop testing after 1a if satisfied, for answering the question: is this in a typical location.

JohnK: Search being usable is a different issue
… Plain language being important
… Sometimes you have to understand and know the sometimes unique terms of the organization to get to the terms you wanted
… Not like common search engines
… This can make a search not cognitively accessible

Shawn: Some common search engines pull up sponsored sites first, and that can complicate the process for people with cognitive disabilities
… Maybe with AI we can help with these search issues for plain language
… This could be part of the behavioral automated test type
… I agree, we can call that procedural testing
… Using behavioral automated testing as part of this

Jennie: just like unit testing that runs a script and validates the outcome

<ShawnT> https://drive.google.com/drive/u/0/folders/1_bQ0rq_C9a6h1RfpcqDmanghsVzP2opO

Minutes manually created (not a transcript), formatted by scribe.perl version 208 (Wed Dec 21 15:03:26 2022 UTC).