– DRAFT –
AGWG Teleconference

<alastairc> EN 301 549 Tool https://labs.etsi.org/rep/HF/en301549/-/issues/219

<Ben_Tillyer> exempt

I'll do first hour. One second.

Intros and Annoucements

So Wendy it is?

thanks!

<ljoakley1> is there a reason that we are not using the transcript feature of zoom?

alastairc: Anyone new or changed affiliation?

Keyboard wrap-up briefing

<bruce_bailey> https://docs.google.com/document/d/1uE2WCxPmvNopdCbuZQm_-cGyEdxEouRmZ8UUIlyutoU/edit?tab=t.7tvvfbgqxbc#heading=h.xlqs7tqpmaam

alastairc: Briefings, Bruce can you do the Keyboard wrap-up?

[screen sharing]

bruce_bailey: We started off with 5 closely related outcomes
… we worked on them in the order given us and we've been meeting for a while
… running notes in the original document
… starting here with 6.2.1 comparable keyboard effort
… around 45 initial user needs
… divided amongst the 5 outcomes
… lots of redundancy, for the next iteration it may help to put these together
… the goal of the subgroup is to have something to publish
… there was an attempt also to break the document into tabs, in the navigation bar on the document everything is there and broken up
… we spent some time on a composite outcome and decision tree
… going to focus now on the 5 we have
… 6.2.1 comparable keyboard effort
… [reading the content of the outcome]
… one concern we have with this is that we need more research or put parameters around it
… two factors are comparable time or comparable keystrokes
… comparable keystrokes is tricky to compare to mouse actions
… there might be user testing to research that, how do you compare keystrokes to mouse actions?
… not feasible for the numbers to be 1:1
… keyboard access is very serial
… point and click is random access
… counting the actions is not similar to one another, but time taken would be relevant
… we wanted to put some parameters around how many keystrokes are reasonable for an action
… trying to figure out what is the upper limit
… 10 keystrokes may not feel slow to some, but extreme to others
… switch input, could feel onerous
… 6.2.2 consistent keyboard interaction
… [reading content of document]
… trying to determine what is "standard keyboard input" was a challenge
… difficult to document, especially over multiple platforms
… no decision tree for this one
… 6.2.3 custom keyboard commands
… change of name, wanted to make it clear what this was addressing
… this has a bit of overlap with 6.2.2, but spent more time here
… one thing we decided early on was to put this on the author
… they know what they are introducing, what they are making active
… decision tree for this one, linear and possible to go through all of the optiosn
… not going to write out all default actions, [reads out content of document]
… one of the things here is that there are considerations for alternative means, don't want to rule out doing things like putting actions on divs
… if it's standard behaviour it doesn't need to be documented, but does if there is
… 6.2.4 keyboard
… big overarching outcome
… all user flows can be completed by keyboard entry
… [reads content of document]
… we did not get far with the decision tree, we were in the process of starting over
… 6.2.5 no keyboard trap
… straightforward, subset of keyboard only
… [reads document]
… decision tree is available for this one
… can navigate whole page, and can exit any element
… tab and shift-tab should have proper behaviours, but not identical/mirrored behaviours
… that's about it
… one more iteration could get something that could go into WCAG3, lots of work remaining

alastairc: The keyboard group is restarting, so if there are any comments, please comment in the document

<alastairc> https://docs.google.com/document/d/1uE2WCxPmvNopdCbuZQm_-cGyEdxEouRmZ8UUIlyutoU/edit?tab=t.7tvvfbgqxbc#heading=h.xlqs7tqpmaam

GreggVan: Why did we not keep looking at the composite?

bruce_bailey: [missed that]

GreggVan: [go to the composite], these are the user needs
… one of the things I found in looking at this, we had all of the user needs
… they kept getting repeated
… we had multiple things that were talked about to solve the same problem
… looking at the tests in the decision tree, and the trees kept asking to do the same things
… same tests run multiple times
… what if we put it into one composite outcome
… grouping all of the requirements together into a single outcome, one goal
… then the user needs collapse into the groups

<kirkwood> +1 to Gregg’s simplification

GreggVan: and the decision tree and tests is one workflow
… more logical approach
… we haven't quite finished this, but it was a single pass through
… there was one other one to mention, of all of the outcomes, expecting the number of commands to be same or equivalent has issues
… speed of random access will never be the same as serial access
… asking for them to be equivalent or near the same is near impossible
… if you find this in other outcomes, where there are lots of repeated steps, it might be worth looking all making a composite

<Ben_Tillyer> +1

GreggVan: fewer but layered goals/outcomes
… allows you to mix in the testable things and best practices
… breaking things down to the smallest element for testability, things will get too granular, similar to WCAG 2 and separated requirements and best practices

<bruce_bailey> s[missed that]/group felt we needed more orientation before building out composite outcome

Ben_Tillyer: Just in response to Gregg, I know we can't directly compare mouse input to keyboard input, there are definitely keyboard commands and multiple steps that users will undoubtedly find more complex
… there is some comparison we can make, but it might not be directly, not 1:1
… I think there is something to look at in terms of complexity or cognitive load
… second point, on the combined tree, I feel that if you had combined all of the different keyboard tests into one, you'd get less repetition, but you may spend a long time getting to one specific test
… if its at the end of the composite tree
… if you're tasked with testing one thing, it may take longer
… if you had a test suite for this, and you remember the steps, or might not remember yourself, the test suite would record your answer, it could be partially automated
… I don't think a tester would ever see the same test they know and run it again

<Zakim> alastairc, you wanted to comment on putting different methods at different levels, e.g. comparable effort.

alastairc: Just going to timebox this as we have other things to do
… the comparable effort item, it could be put at a different level
… the fallback could be to assess whether there are more efficient ways to adjusting the UI for keyboard user

<bruce_bailey> +1 that "comparable effort" should be higher level

alastairc: in the supplemental requirements, have a stronger requirement about the comparable time/effort
… couple of potential ways to deal with this one

Detlev: My comment is that, I'm unsure whether the tree as presented would be how people test
… keyboard is something that's manually tested, the assumption may be that each test runs through the tree, but that may not really be how people do the tests
… the question is whether more a theoretical semantic process to assess the process
… or for use in the field?

<Ben_Tillyer> That echoes my understanding Detlev

alastairc: The decision tree is for people to assess what methods to use
… but we are still working out how the structure works for different guidelines

Rachael: Agree with the last part, don't get too stuck
… it's not a testing tree, as designed now, as it has evolved, it asks what guidelines apply
… not on a per-item basis

<alastairc> It may help to review the examples in the upcoming WCAG 3 publication (in two agenda items time).

Rachael: but if we got to an application and it had images of text, based on the decision tree, I know this will work because the tools can support the function
… more asking what criteria you're testing again, not how you're testing on a step-by-step basis

alastairc: Move on to a brief presentation from Gregg from a new tool

Intros and Annoucements

alastairc: might be inspiration for WCAG3

Issue 2296 https://github.com/w3c/wcag/pull/2296/files

EN 301 549 Tool https://labs.etsi.org/rep/HF/en301549/-/issues/219

GreggVan: EN 301549 is the interational version of Section 508
… it directly uses WCAG
… for both web and documents and software
… there are 287 different provisions in it
… it is designed to make it easy to what applies to your particular product

<kevin> s/international version/European version/

GreggVan: I have a video here showing the product, how it works

GreggVan: [showing video]

<alastairc> audio-desc of the video: Showing a spreadsheet of provisions in a nested structure.

<kevin> s/European version/international version/

<alastairc> audio-desc of the video: Showing a table of provisions which can be checked / unchecked.

<alastairc> Ben - this is part of the process for creating the next version of the EN (see the link in the agenda above)

<alastairc> I think it is created by Gregg as a demo.

what specific tab in the workbook are you referencing in the demo?

<ShawnT> There is a tool already available which we are working on updating it. ICT accessibility requirements wizard

GreggVan: That gives a quick overview, are there any questions?

dan_bjorge: This looks like a useful starting point, I would hesitate describing it as not requiring judgement calls
… there are still some in there
… I would want more guidance if I were someone filling this out, maybe links to more context
… what is "communication client"? To add to make it more useful

GreggVan: What I meant was no judgement based on the maker, but on the user, yes

<Zakim> ChrisLoiselle, you wanted to ask what specific tab in the workbook are you referencing in the demo?

GreggVan: that's a good suggestion, I tried to include some cues, but linking it to definitions or a help doc, that is a superb idea

ChrisLoiselle: I know you showcased many different tabs, is that a specific tab for the different functions?

GreggVan: Yes, there's 4 tabs, the captions covered it up
… there's introduction, provisions, report
… as you check the checkboxes, the provisions page will hide the provisions
… the printout just gives you everything in one place
… that report doesn't just give you the filtered list and the reasons why its filtered
… so someone else may be able to check for errors

ChrisLoiselle: Great, thank you

GreggVan: I just noticed there is a bug, so I'll put up a clean copy
… here is a link to the latest version of EN 301 549 and the tool are both available
… in a public location
… don't download it quite yet until I fix it

<GreggVan> https://labs.etsi.org/rep/HF/en301549/-/issues/219

GreggVan: There's a bunch of things going on in there, there's bug in there, it pops an error on launch

Keyboard wrap-up briefing

Issue 2296 https://github.com/w3c/wcag/pull/2296/files

alastairc: Ok next topic, we have gone through the CFC process for WCAG 2.2 errata updates
… there was one that hasn't made it through, we just need to go through the process
… the change is in the link

https://github.com/w3c/wcag/pull/2296/files

alastairc: Changing the index in the introduction, it's linking through to the supplemental guidance
… was once a longer link, it's just updating it to go to the right place
… supplemental guidance, which goes to all of the guidance
… asking does anyone have any issues wit this update?

<alastairc> Update: We encourage authors to refer to our <a href="https://www.w3.org/WAI/WCAG2/supplemental/about/">supplemental guidance on improving inclusion</a> for people withh disabilities, including cognitive and learning disabilities, low vision, and more.

alastairc: If no issues, is this a reasonable update to include in the errata publication?
… if so, we'll tag it on to the CfC

<alastairc> draft RESOLUTION: accept PR 2296 to update the Background section of WCAG 2.2 and 2.1

<Glenda> +1

<julierawe> +1

<wendyreid> +1

<Ben_Tillyer> +1

<Chuck> +1

<Francis_Storr> +1

<Laura_Carlson> +1

<mgarrish> +1

<bruce_bailey> +1

<GreggVan> +1

<dan_bjorge> +1

<kirkwood> +1

<ShawnT> +1

<Jennie_Delisi> +1

<ToddL> +1

<scott> +1

<LenB> +1

<ChrisLoiselle> +1

<Rachael> +1

<kevin> +1

<mbgower> +1

<Gez> +1

<ljoakley1> +1

RESOLUTION: accept PR 2296 to update the Background section of WCAG 2.2 and 2.1

GreggVan: One thing from the last topic, the where structure, "where this is true"
… it might be useful for us to consider structuring WCAG in a similar structure, we have it now, but adopting something similar in our own documentation

WCAG 3 w3c/wcag3#129

alastairc: Next item is WCAG3 updates
… have a PR up

<alastairc> Preview: https://deploy-preview-129--wcag3.netlify.app/guidelines/#

alastairc: a preview is available as well

alastairc: We had a few thoughts from Hidde, mostly editorial and incorporated
… question about Voice Control, nothing to add for that yet
… this is something we are looking at
… questions about email

WCAG3 - check acknowledgements

alastairc: subtopics, the acknowledgements
… tried to update them

<GN015> There might be some further topics to add in the future. Can you please remind where to find the parking lot?

<Rachael> acknowledgements: https://deploy-preview-129--wcag3.netlify.app/guidelines/#acknowledgements

alastairc: If we are missing anyone, please let us know

WCAG3 - definitions

alastairc: Feedback on the definitions, they have been added
… or the things referenced from current guidelines, or TBC as we don't have content
… taken from WCAG2, or being worked on
… marked as exploratory or developing
… any other comments or questions?

Rachael: Just to say that we pulled the terms from the content moving to developing from exploratory
… as we move from exploratory, we add the terms then

WCAG3 - numbering

bruce_bailey: Just noticed with acknowledgements, sometimes its "Invited Experts" or "Invited Expert"

alastairc: There was a question on numbering and adding numbers in
… question is how desirable it is
… I know previously some people thought it was a mistake, giving numbers to the SCs, if numbers are referenced not names
… and at this stage, they will move around and aren't referenceable
… if there are other thoughts we could open up a discussion on that

<Zakim> Chuck, you wanted to ask for a scribe change

Gregg: hard to find things with short names (if they aren’t in alpha order). We might want to go with simple sequential numbers (like an ordered list) at this stage. Example: I’m taking about Keyboard Access #32.

Julie: if numbers are concerned for referencing, what about bullets. Some of the sections are so long, it is helpful to have a way to keep track of what level I’m reading. Very hard to follow and the indentention and font sizes aren’t helping enough.

<Zakim> alastairc, you wanted to comment on other mechanisms

Alastair: we might be able to use accordians

WCAG3 - scope (to web)

<tiffanyburtin> +1 Julie to additional methods to help visually chunk the information to help it be a bit more readable

Alastair: How does this apply to native mobile apps and non-web context. Current charter restricts us to web tech. So we may get more flexibility in our next charter, we will try. Then it is a matter of how do we enable the structure for other types of tech.

Julie: inconsistency, sometimes we say WCAG 3. Sometimes we say WCAG 3.0. We need to be consistent.

Alastair: are we ready for a resolution Rachael?

Rachael: We have some editorial changes. And we have a few pull requests. Are we comfortable to make this editorial changes and give you 2 days to review and move to CFC at end of this week?

<alastairc> draft RESOLUTION: Approval for merging the changes into the Editors draft in preparation for CFC for publication

Julie: Are you including formating the guidelines section so it is easier to navigate?

Rachael: Yes

Chris: My email about scope beyond web, was just clarification.

<alastairc> draft RESOLUTION: Approval for merging the changes into the Editors draft in preparation for CFC for publication

<Detlev> +1

<ShawnT> +1

<ChrisLoiselle> +1

<Chuck> +1

<Laura_Carlson> +1

<Jennie_Delisi> +1

<Rachael> +1

<Makoto> +1

<Ben_Tillyer> 0 been away for a few weeks, haven't reviewed

<LenB> +1

<mgarrish> +1

<Francis_Storr> +1

<Gez> +1

<Glenda> +1

<MJ> +1

<tiffanyburtin> +1

<GreggVan> +1

<bruce_bailey> +1

<ToddL> _1

<ToddL> +1

<filippo-zorzi> +1

<kirkwood> +1

<julierawe> +1

RESOLUTION: Approval for merging the changes into the Editors draft in preparation for CFC for publication

<Chuck> Views: https://docs.google.com/document/d/1pN6zc0YjxY2TmhmrSii0Y5ghzjdNOqMV5F4a_Dfqsyo/edit?tab=t.0#heading=h.7bct10877dbh

<Chuck> Voice Control: https://docs.google.com/document/d/1IpVHc8-PRn7z-wqZ32G4zG4CjFdZT0HAJ787WfUxNP0/edit?tab=t.0#heading=h.nykct8nbnejl

<Chuck> Text Contrast: https://docs.google.com/document/d/1BIcyTcyGz-vb6FCAzzhXcXFukktgjUU6-dM0rYsuYMM/edit?tab=t.0#heading=h.4fu2rk4qoiti

<ShawnT> Text to speech: https://docs.google.com/document/d/13NASXgLB6yVtZJqiN-HsD1xOIffOXbe0/edit?usp=share_link&ouid=114934085576672059156

Alastair: we will not be coming back afterwards