AGWG Teleconference -- 27 Feb 2024

<laura> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

<bruce_bailey> scribe: bruce_bailey

<laura> Scribing Commands and Related Info https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

alastairc: Any introductions?
... announcements?

Project Plan check in

<alastairc> https://www.w3.org/WAI/GL/wiki/WCAG_3_Timeline#Publication_Plan

zakim take up item 1

[alastair screen shares doc]

alastairc: Picking a few outcomes, and setting up subgroup on those.
... also subgroup on publication approach
... also subgroup on conformance models has regrouped and will present back to AG
... group will also be working on assertions

Rachael: if anyone wants to do deep dive reading, see link. Background et al. may be a couple hours reading

WCAG 3 Requirements updates

alastairc: Questions?
... we had a few meetings on wcag 3 requirements , have been working through those...

making edit or responding to questions

<Rachael> Conformance Model History: https://github.com/w3c/silver/wiki/Conformance-Proposals-2018-to-present

Requirements editorial changes #619

https://github.com/w3c/silver/pull/619

[alastair screen sharing]

Not much conversation, very much editorial...

Gundula noted defect from earlier, but that should be a new issue

Use well defined normative language [Deque feedback] #371

Will remain open for 5 days and then be merged.

<dj> https://github.com/w3c/silver/issues/371

https://github.com/w3c/silver/issues/371

alastairc: Melony asked about technology normative requirements.

Rachael: I did not understand if clarity applied to which part of requirements?

alastairc: I had assumed it meant normative requirements

<alastairc> "Normative requirements should be unambiguous so that there is only one possible meaning for each requirement."

alastairc: any other suggestions?

graham: Please could use less developer-oriented terms...
... for example "accessible name" is technical jsargon

alastairc: Agree to bring back to sub group for feedback, but for outcomes we would want that specificity

Glenda: wrt Graham's point, for high levels should be technology agnostic, and then HTML examples.
... at Deque we have high level goal then HTML example

alastairc: We have concurrence on being unambiguous , and not all needs to generic

Update "Motivation" section #731

<alastairc> https://github.com/w3c/silver/pull/731

alastairc: As with other topics, 5 more calendar days to comment please.
... Shadi pointed out that we had scoring as THE way to motivate organizations...

,,.PR changes "scoring" to "conformance model"

Rachael: There are two issues which have somewhat contradictory phrasing, so that should be resolved.
... i only thumbed down so this is not missed.

[alastairc works through paragraphs on screen]

<dj> https://github.com/w3c/silver/issues/466

<alastairc> Propose we use issue 466 https://github.com/w3c/silver/issues/466

alastairc: I propose we keep issue 466 which is slightly clearer. Anyone with strong preferences for the other?

Gregg: I would use the one with our intent -- but we say we will NOT do something, that might box us in.
... not sure which of two that is.

<alastairc> Suggesting we use "The Guidelines motivate organizations to go beyond minimal accessibility requirements by structuring WCAG 3 to provide encouragement to organizations which demonstrate a greater effort to improve accessibility."

alastairc: We may a third proposal developing. Both changes remove "scoring".

<GreggVan> +1

Rachael: The difference was "structure" versus "conformance" in the other.

GreggVan: +1

<rscano_> GreggVan +1

[alastair updates issue comment]

alastairc: We had a couple of questions about 4.7...

Including informative documents as a design principle #307

<alastairc> https://github.com/w3c/silver/issues/307

alastairc: This was asking for informative documents as part of the work.
... we could have a requirement for informative docs but that does follow from our principles
... Rachael proposed a couple ways to phrase.

<alastairc> Proposing to add: "There should be accompanying documents that provide clear, concise, and findable technical information (methods, how-tos) quickly in one place."

alastairc: this will be more of a change rather than a response.

<kirkwood> +1

dan_bjorge: +1 in general, but is "methods" too specific?

<alastairc> Updated proposal: There should be accompanying documents that provide clear, concise, and findable technical information quickly in one place.

alastairc: Any other suggestions or concerns?

GreggVan: Another reason to remove parenthetical is that "one place" implies single web page.

alastairc: Again, 5 more days to comment.

Guidelines focus on functional user needs #311

<graham> https://github.com/w3c/silver/issues/311

https://github.com/w3c/silver/issues/311

[alastair paraphrases comment and response from issue]

alastairc: We are still working on best way, but not making changes to requirement document based on this feedback.
... any questions or feedback?

Require AT testing in Design Principles and Requirements #344

<alastairc> https://github.com/w3c/silver/issues/344

Proposed response to 311 accepted.

alastairc: Another fairly short question and response.
... Any concerns with response in issue thread?

<kirkwood> testing ‘with’ assistive technology rather than ‘on’ not sure i misread

graham: Not all of course, but there could be mention of best practice to test on a couple screen readers...
... not needed all the time, but some things are more subtle.

<jon_avila> +1

Rachael: These requirements will be used as exit requirements. I agree we will likely have methods or assertiions that use AT testing but putting it here would require it for everything.

kirkwood: Testing on AT versus WITH AT ?

<jon_avila> who removed me from queue?

GreggVan: I think we should be careful since we are talking about requirements on guidelines, not the GL themselves...

<rscano_> Agree with GreegVan... also we will enter in the doungeron: which AT i need to use for test? :)

GreggVan: so mention that good way of testing is with AT -- but is not always -- but testing the requirements of the GL is not the same thing.

<kevin> +1 to Gregg's comment

alastairc: Agreed, this is the requirements document, not the requirements for GL

jon_avila: There will be methods that need to be tested with AT, but other parts of conformance might not. So should that be clarified?

alastairc: That seems different than what the requirements document is trying to do.

<graham> I just realised, is the OP asking whether we should specify "test this on JAWS, NVDA, Orca" etc. as if that is the case I am very much on the "no" side to this issue as that would lead to "what about this obscure screen reader" etc.

GreggVan: Could mention "accessibility supported" is still a under discussion.

alastairc: That is another topic.

dj chase: In response to require multiple ATs, but we should not be too aggressive about that...

<alastairc> Tangent: https://github.com/w3c/wcag3/discussions/53

scribe: we would not testing to require purchase of multiple commercial products.

alastairc: off topic for today -- but upcoming (see link)
... If people comfortable with response, please thumbs up.

Email: ITI Comments on First Public Working Draft of W3C Accessibility Guidelines (WCAG) 3.0 (9 - Requirement for automation only level) #451

<alastairc> https://github.com/w3c/silver/issues/451

alastairc: is response to Q about other principles. Proposed response from Jeanne in issue thread.
... so response is not one way or the other, but does not impact requirements for WCAG3.

dan_bjorge: If we were to go this way it WOULD impact requirements document...

<Chuck> +1 I don't recall a formal decision.

dan_bjorge: i thought there was concurrence that automated testing compatible is NOT a requirement for normative parts

Rachael: We do not have an expectation for "automated level" but at this stage we still should keep requirements document flexible.

GreggVan: Agree we do not need in requirements document.

alastairc: Is there a change for requirements document?

GreggVan: Still seems could have impact on structure.

<Rachael> Note that there is a difference between "requirements document" which is what we are working on and "requirements as written as SC in WCAG 2 and Outcomes in WCAG 3"

<Rachael> Just noting an overloaded term

alastairc: In general , trying to keep our options on our requirements document -- which is part of what wcag3 will be judged on...
... so at this stage we do need to be careful.

<Chuck> +1 no objections

alastairc: Does any object to response from thread?

Email: Intopia Feedback - WCAG 3.0 FPWD (1 - Requirements) #466

<alastairc> https://github.com/w3c/silver/issues/466

alastairc: If strong counter opinion, please add to issue thread.
... Question about scoring system and motivation, please see proposed response.
... We have removed the bit they expressed concern for. This is somewhat duplicative from another issued we discussed this morning.

Rachael: This related to the issue where we had two possible responses, so this now resolved.

About: needs don't tend to fit the true/false model #223

<graham> https://github.com/w3c/silver/issues/223

alastairc: Salesh asks about true/false versus other scoring, long thread, but do have response at end.
... It is a fairly conversation reply to conversational comment. No change to Requirements document.

[alstair incorporates Rachel's suggestion from thread]

alastairc: Any questions or comments?

graham: Was not goal for WCAG3 to scale so that one missing alt out of thousand is better that just "fail"?

Rachael: Earlier draft was very oriented for scaling and scoring and counting -- and we got a great deal of negative push back to the accounting...
... we are not finished with the conversation however, as conformance remains open.

First set of outcomes

<alastairc> https://github.com/w3c/wcag3/discussions/51

alastairc: This is a discussion of our first group of outcomes...
... Rachael proposed five

<alastairc> https://github.com/w3c/wcag3/discussions/51#discussioncomment-8471208

alastairc: nine thumbs up on the five, and no alternative suggested
... Any other concerns?

dan_bjorge: I do think this is a good pass of diverse set but...
... do we want to target contentios requiremenst -- such as color contrast

Rachael: We had conversation, but decided to pick up on second round.

alastairc: Only positive feedback, so we will proceed.

<Rachael> So Visibile Keyboard

Rachael: Visible keyboard focus will be the first outcome we pick up

Structure with Examples https://docs.google.com/document/d/1tpgJaoIHC4IywvFkfXrfa8mEcSlEtAP-P0_46vNqynY/edit#heading=h.vc6kiqsxgozk

<alastairc> scribe: alastairc

Rachael: Continuing the conversation from last week, adding examples.
... It seemed that we had three structures that people thought were best.
... I moved the user-needs out for the moment.
... the first structure is where the tests & assertions are under each method.
... the second is where methods and assertions are siblings.
... the third option grouped quant / qual / assertions as siblings.
... This first example is a "best guess" wording at this stage, it's just an example to show how the structure works.
... 1st - tests and assertions under the methods.

(reads from doc)

Rachael: The second method is something that goes beyond WCAG 2, with a qualitative test.
... none of this is 'real' content, but looking at the structure.

Gundula: Question on the 5 users of AT, who are often blind, how could they agree that it's equilvelent.

Rachael: We'll need to work that out under the assertions, but not a question for today.

<Chuck> scribe+ Chuck

<kirkwood> “the purpose” of the image should come from the author

<Zakim> alastairc, you wanted to comment on tree-structuring the level under methods

<Chuck> alastair: Chair hat off question... Wondering if its possible to put into the structure some kind of leveling. I can see that if you had an assertion that was more difficult...

<Chuck> alastair: maybe not 5 at users, maybe a laborious testing procedure, that got to confident results that the page/view/site works, even if there are some missing alt text on images, but pass the assertion one

<Chuck> alastair: which we consider more robust... it's not something we need to tackle now, but its the first thing that occurred to me.

<Chuck> alastair:... you can do this basic thing, or this difficult thing...

<Zakim> Rachael, you wanted to give chair hat off response to Alastair

graham: Thanks for the examples. Thinking, we've got 5 good test-cases, why not write them as a ... but I'm not sure that I can see how it's going to work across them.

Rachael: We are looking to pick a couple of variations to try, then the content-groups can try these out. Don't want to try the 20 odd variations.
... this conversation was to pick the variations we start with.
... To Alastair's point, I think assertions should do under the guidelines, so that kind of work is testing as much as possible at one time. Also
... The next variation is Methods & assertions under outcomes, so it gets more specific.

<David_Cox> Having assertions under methods does appear to be likely to create duplicate assertions, yeah.

Rachael: the assertion is at a higher level, so that you can test either/or, rather than both/all.
... then for the Qual and Quant methods. In WCAG 2 there are parts which are quant and parts which are qual, in the same SC.
... this would be a way to support more automated testing, rather than having them combined in the same level.
... however, it does get a bit repetative.
... it almost gets to the test level in the methods.
... Example 2, text contrast as a more quantitative outcome.
... So the question to the group, do all of these seem reasonable? Any preference?
... but keep in mind it's a lot of work to re-write everything!

David_Cox: For example 2, the assertion is under the outcome, should that be tabbed in?
... to me an my brain, the method sounds like the 'technique', but in this case they are used as if/then statements?
... is there a way to delineate these into a flowchart, or use various methods?

<mbgower> +1

Rachael: It's a good question, the intent (from memory) is that the methods are "or", and each tech-specific solution should meet it.

dj: I have some concerns with the 2nd and 3rd, e.g. example 2, the second method is kind of redundant or unecessary, do they all need qual and quant methods?

Rachael: I'd guess some won't, but many would
... it would necessitate "ands" between the structure.
... wouldn't highlight "qual" and "quant" to the public, that's for us.

dj: Like the assertions under the outcome, when under the methods it adds redundancy.
... makes it more dense.

Chuck: (chair hat off), prefer option 3, I think because of the assertions.

dan_bjorge: How, in practice the methods/tests gets combined. Discussion about examples where different methods represent different technologies. These examples, in most complex websites, you'd need most methods to assess the outcome. It would be multiple methods per view.

<Frankie> +1 to preference for Option 3, for both the treatment of assertions and user needs

dan_bjorge: when you have cases where in WCAG 2 we'd have bullets, there isn't one way to combine them, it might be a range of options. So I'm concerned about something that is to one-size fits all.

GreggVan: Example 3, I thought that we were doing assertions as a quantitative method, you're testing whether they made an assertion.
... qual and quant not quite right (objective / subjective). But an assertion goes from subjective to objective, as you made it.
... an assertion was our way of saying something if we can't test it. E.g. "Did you try to do this", but you make it an assertion it's testable.

<kirkwood> +1 to Gregg

Rachael: Does another structure work better? E.g. a single method backed by an assertion?

GreggVan: Why have an assertion if you have a test?
... an assertion should be under quantitative.

<Zakim> mbgower, you wanted to say that to build on what David said, there could be reusable methods that could be applied, alone or in tandem with other methods, to achieve a number of

<kirkwood> +1 to Gregg

mbgower: In response to the assertion, an assertion is an author supplied criteria, and you're checking for whether it exists. I agree it is quant.
... building on David's comment, about reusable methods. Those are very useful ways to build things, and fits granularity of ACT.
... still not sure, we need to drill down and find a well-worded set of outcomes, methods, assertions.
... I'm not sure how to talk about teseting without some sort of flow process? Do this, then this, then this. If there's a way of doing that with the methods being isoliated and unique, that would be great, I can't work it out.

<Zakim> David_Cox, you wanted to comment on assertion placement

David_Cox: Generally, I'm leaning towards second option within both examples. If assewrtions where under the guideline, I don't think that would work. You might have outcomes based on unrelated tech/concepts, that makes more sense to me.

<Zakim> Rachael, you wanted to say the structure dictates whether the method is AND or OR

Rachael: Just wanted to point out, the and/or, whether it's tests under methods (and that's a way to support the outcome), does depend on the structure.

dan_bjorge: One piece of feedback, previously, was a concern about nesting and complexity. In example 3 methods and tests are 1:1. Is that how it would work in practice, or just this example?

<David_Cox> On concerns about nesting, nesting is basically the same as building a flowchart. I

dan_bjorge: could those be collapsed.

<Zakim> alastairc, you wanted to comment on confusion from assertions as objective.

<David_Cox> d recommend we do go for a 'flowchart' type thing, where everything can be mapeed to a series of if/then statements.

<kirkwood> +1 to reduction of complexity observation

<David_Cox> *I would recommend...

<Chuck> alastair: Gregg & Michael talked about assertions. I think from a public/tester point of view, an assertion requires a lot to do in order to do it properly.

<Chuck> alastair: It makes sense to separate it from the quantitive, it's its own thing. There's a chunk of work that is not quantitative.

<Zakim> Chuck, you wanted to say that whatever approach we take, we are not backing ourselves into a corner

Chuck: I expressed an afinity for 3, but we're not going to loose work or waste time exploring any of these options.
... not opposed to any of these.

<kevin> +1 to Chucks comment

<David_Cox> +1 to complex nesting adding usefulness in-practice

<mbgower> Here's another outcome to consider "The text equivalent conveys no additional meaning beyond the image"

Rachael: we need to think about the complexity of structure vs complexity of use. I think "2" would be less complex to use. E.g. I'm doing an HTML page, I want that method, and what I need is there.
... however, without that extra layer (in 3), we need additional guidance to say which method to use.

GreggVan: I added another option at the end. Groups quant methods (including assertions). Under the qual methods, so I think this more accurately represents what we're doing. You could also make the qual method into an assertion (because you're asserting you've done it.)
... this always assumes that companies will make assertions, but it's a way of getting it in.

<Zakim> Rachael, you wanted to comment on Gregg's suggestion

Rachael: I have a lot of concerns about this, not sure it works with the other guideline.
... sort of agree, noting that the levels are essentially: Objective, somewhat subjective, and very subjective.
... this is about reliability of results. By picking up and combining the examples, it could reduce requirements from wcag2.

David_Cox: Fully agree that as designers of a standard, it's easy to see complexity and flatten things. But as the end-user it could be done more simply. E.g. the one-thing per page approach to forms.
... don't think we should worry about nesting depth.

<Rachael> ak dan_bjorge

David_Cox: and +1 to thinking about the users of the info. The smaller the amount of things to hold in your head at one time is good.

dan_bjorge: agree in principle that nesting isn't the problem on it's own. But one of the bigger sources of confusion for WCAG 2, is where info is repeated in slightly different ways between sections. E.g. SC to understanding.
... where we have that kind of duplicaiton it creates opportinity for variations.

<David_Cox> +1 to Dan's point, that's a good clarification

<Zakim> mbgower, you wanted to say that if we REALLY work these two sets of guidelines/outcomes to try to come up with great methods, it may help discover glitches/successes in the

dan_bjorge: on assertions vs testable outcomes, and whether companies will use it. I'm worried in the other direction. I think we should not create cases where an assertion is an alternative to the testable version. It's really easy for a big company to find 5 users to say something is fine

<mbgower> Here's another outcome to consider "The text equivalent conveys no additional meaning beyond the image"

mbgower: I'd hope we come up with detailed outcomes soon. That will help us find the edges.
... thinking about the problems we've seen, we should catch more cases.
... I'd like to help with that.

Rachael: We just need to make a decision on which option we start with.
... we don't seem to have thrown out any of the 3.
... should we pick 2? Or is there one we've missed?

<Rachael> Straw Poll: 1) Subgroup works on all 3 example outcomes 2) Subgroup works on 2 of the 3 3)Subgroup works on more than the 3 example outcomes

<Chuck> 2,1

<ljoakley> 2,1

<Glenda> 2,1

<GN015> 3, 1

<GreggVan> 1 or 3

<Rachael> 2,1

<Frankie> 1, 3

<ShawnT> 2,1

<dj> 3,1

<mike_beganyi> 2, 1

<laura> 2,1

<kirkwood> 2,1

<JakeAbma> 2,1

<Jon_avila_> 2

<dan_bjorge> 2

<Francis_Storr> 2,1

<GreggVan> 3,1

<Gez_Lemon> 2, 1

<jeanne> 2,1

<kevin> 2,3

<David_Cox> 2,3

<mbgower> 2,1

2,1. I don't think we can do that many variations.

<shadi> 1

<Rachael> Assuming we pick 2, which two:

<Rachael> 1) Tests & Assertions Under Methods

<Rachael> 2) Methods & Assertions Under Outcomes

<Rachael> 3)Qualitative & Quantitative Methods

<Rachael> 4) Gregg's proposal

<Chuck> 3,1

<David_Cox> 2 & 3

<jeanne> 2,1

2, 3. Preference, no objection to any

<kevin> 2,4

<dj> 2 & 3

<mike_beganyi> 2, 1

<JakeAbma> 2, 3

<Rachael> 2,1

<kirkwood> 4

<ShawnT> 2, 4

<ljoakley> 2

<Frankie> 2, 3

<dan_bjorge> 2, 3 I guess? Don't think assertions should ever be a peer to non-assertion methods, so not a fan of any

<GN015> 1,4

<Glenda> 4

<Jon_avila_> 2

<GreggVan> 2, 1

<scotto> 2, 3

<laura> 4, 1

<kirkwood> 4, 2

<rscano_> 2,3

dan_bjorge - I think we can put some mitigations in place, e.g. part of the assertion is that you're doing automated checks for missing alts as well as the more subjective part.

<Chuck> 5 1's, 14 2's, 9 3's, 6 4's

<Chuck> 7 4's

<Rachael> Draft RESOLUTION: Explore options 2 and 3 for structure in the first subgroup and report back

<Chuck> +1

<mike_beganyi> +1

<dj> +1

<jeanne> +1

<David_Cox> +1

<rscano_> +1

<laura> +1

<Francis_Storr> +1

<Gez_Lemon> +1

<Jen_G> +1

<kevin> +1

<Glenda> +1

<dan_bjorge> 0

<Frankie> +1

<Rachael> https://www.w3.org/WAI/GL/wiki/WCAG_3_Timeline#Publication_Plan

RESOLUTION: Explore options 2 and 3 for structure in the first subgroup and report back

Rachael: We're setting up the first outcome sub-group, feel free to get involved!

- DRAFT -

AGWG Teleconference

27 Feb 2024

Attendees

Contents