AGWG Teleconference – 30 November 2021

Wilco: silver reliability TF was formed to write methods and outcomes consistently.
… methods to become ACT rules.
… document for the process that we can follow.
… begins with a Brief outline
… It addresses a clear user need. There is little to no room for interpretation. It is quick and inexpensive to test (possibly using tools). It is easy to learn.
… Why Testability Matters. Many roads just have a speed limit.
… WCAG 2's strong emphasis on testability is part of what made it so appealing for organizations to adopt.
… Writing testable outcomes is a highly iterative process.
… takes dozens of iterations before an outcome is good enough.
… Come up with examples and edge cases
… Step 2 is to create a rough outline of the outcome
… Step 3 is to define the terms used in the rough outline.
… Step 4 is to simplify where you can. There are several things that can be done to make an outcome easier to learn, and easier to test.

Step 5 is to complete the How to & methods

Step 6 is to get feedback, and iterate
… Additional examples / edge cases. Change categorization of particular examples. Requests to adjust any ambiguity, subjectiveness, or nuance.

<Zakim> GreggVan, you wanted to ask "should there be a step that checks for inter-evaluator agreement?"

Gv: this is really good.
… Is it missing a step on inter-evaluator agreement?

Wilco: that is part of the definitions in step 3. Leave a comment in the doc.

jake: question on testability.
… for WCAG 3 coga needs more subjectivity.

<Fazio> I like that quote. Nice Jake

<AWK> +AWK

jake: how to cope with things that can't be counted objectively?

<Zakim> jeanne, you wanted to say qualitative and subjective and identifying user needs

Wilco: will answer that soon.'

JS: this doc is about how to write guidelines. User needs must be identified first.
… continue to iterate.

Jf: protocols will try to address some of that.

<Fazio> There are some official COGA SC's too though

Jf: protocols reinforces best practice. Looking for help.

<Fazio> those wouldn't be protocols

wilco: Testing Qualitative Aspects. WCAG3 tries to take the qualitative question of “How accessible is it?” and turns it into the quantitative measurement. In doing that, it takes an unbound quality like “accessibility” and constrains it in a way that can be quantified.

<Fazio> visual contrast now :)

wilco: what text to be legible by measuring contrast.
… look for indicators that we can measure as part of the requirements.
… Handling Ambiguity and Subjectivity.
… An outcome is ambiguous when there is more than one way to explain what it means. An example of ambiguity is the word “heading”.

<Fazio> ambiguity typically favors a plaintiff that wasn't involved in drafting the language

wilco: Someone might take that to mean anything that is visually presented as a heading. Another person might decide that something is a heading because of its markup, or because of the function.
… Subjectivity is different from ambiguity, in that an ambiguous outcome is one where the meaning can be disputed, a subjective outcome is one where the degree to which is met can be a matter of opinion.
… Soundness of Outcomes: want outcomes that work.
… images need a text alternative.
… need to document.
… plain language is an example.
… count words or letters.
… count common words.
… different metrics that you can use.

<Zakim> jeanne, you wanted to say that rubrics are included as a possible solution to subjective

JS: In the subjectivity section is alternatives for binary tests.
… narrow down subjectivity by good better best, rubric solutions.

Wilco: How Nuanced Should Outcomes Be?
… example on contrast. 4.5 or 3 in WCAG 2X

<JF> and 7:1 @ AAA

Wilco: will be a challenge. It will be negotiated.

<GreggVan> all web content - we should be sure the WE know how to apply it across the spectrum of pages on the web

Rm: will survey this next week.

wilco: will work with other groups to try this out. Survey would be great.
… this is an internal doc.

<Zakim> GreggVan, you wanted to say "I think you might also include a step that says -- demonstrate how that the provision can be successfully applied across a spectrum of the pages on the web (that the provision would be applieed to) covering a wide variety of page types and content (from children’s to scientific, from information to e-commerce, from verbal to visual, from functional to artistic). RATIONALE: Before we create a guideline that could be applied across

Gv: think you might also include a step that says -- demonstrate how that the provision can be successfully applied across a spectrum of the pages on the web (that the provision would be applieed to) covering a wide variety of page types and content (from children’s to scientific, from information to e-commerce, from verbal to visual, from functional to artistic).

Wilco: agree.

Gv: could be in the simplify section.

wilco: that is section 4.

Jf: rubrics have not been agreed to by the WG.
… it is an open question.

WCAG 3.0 Requirements https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/results

RM: Issue 242 suggests changing the word web to the word digital to align the scope in the abstract.

Request to change web to digital in Abstract

: RM: Issue 242 suggests changing the word web to the word digital to align the scope in the abstract.
… The suggester drafted PR 243.
… 8 Agreed with the change.
… wilco agree with change with some adjustments.
… 7 Something else.

<Rachael> https://github.com/w3c/silver/pull/243/files

( reads comments)

Gv: should have a disagree option. And a way to comment.
… Judy made a comment "not quite". Getting fuzzier.
… turn to Judy to get her thoughts. Can't walk outside of our charter.
… Need to understand.

MP: changing to digital not in line with out charter.

awk: will cause charter challenges.

<Rachael> themes: charter concerns, alternative is to leave as is and use response

Judy: need to not claim outside of charter. Concerned with just web content. We are doing far more than that.
… there were objections to a broad scope.
… but we are working on many kinds of technologies.
… we should be careful.
… history from the charter. Don't be broader or narrower.

wilco: are things like emulators in scope?

<Zakim> Judy, you wanted to react to Wilco_

Judy: Dom did an interesting thing with web in mobile.
… there is a whole continuum of things. It is all relevant.
… discourage mixing platform and content.

Jg: we not making laws for governments. But it is applied to other things.
… harder for organizations to adopt if not expanded.

<Fazio> Wow. This conversation is so confusing I'm getting dizzy

Jg: definition may need to evolve.

Gv: used to be defined by a web page rendered in a browser.

<Fazio> That would be great, but yeah complicated

<AWK> +1 to Gregg.

Gv: all digital apply to my watch, washing machine, car.

<Fazio> If you think in terms of the Boeing crashes, perhaps it would be best if we applied wcag

Wilco: native apps can render web. Could consider the opposite.

<Fazio> Can't we publish Notes on how to apply to non web digital?

ac: follow our charter. But allow to use it to be used for native.

<Fazio> Notes aren't official standards

<Rachael> straw poll: Option 1) Leave it as is and respond per Alastair's suggestion 2) Change it to web technologies throughout and create new response 3) Something else

ac: better define web technologies.

<Zakim> alastairc, you wanted to try to resolve the issue raised.

<Rachael> straw poll: Option 1) Leave it as is and respond per Alastair's suggestion 2) Change it to web technologies throughout, create definition of this, and create new response 3) Something else

Jf: +1 to getting a definition of web technologies

<Rachael> https://www.irccloud.com/pastebin/ja0oF8g8/

<Rachael> straw poll: Option 1) Leave it as is and respond per Alastair's suggestion 2) Change it to web technologies throughout, create definition of this, and create new response 3) Something else

<Wilco_> 2

<Fazio> 0

<GreggVan> 1

<Judy> 2

<ShawnT> 2

<Chuck> 2

<jeanne> option 1, can live with 2

<MelanieP> 1

<alastairc> 1 then 2

<Rain> 2

<janina_> +2

<JakeAbma> 2

<kirkwood> 1

<ToddLibby> 2

<Jaunita_George> 2

<Lauriat> 2 or 1

<GreggVan> 2

<Rachael> 2

<sarahhorton> 2 but may need to revise wording

laura: 2

<JF> 2

<AWK> 2

<Fazio> 0

<Raf> 2

<michael> 1 or 2

<Francis_Storr> 2

<Fazio> +1 Gregg

<Fazio> I think that was Gregg

<Chuck> scribe change?

GV: definition would be a W3C scope not WG scope.

Jg: concerned about defining too narrowly.

<michael> Wcag2ict

Jg: emerging technologies need to be considered.

<GreggVan> +1 to alistair's suggestion

<kirkwood> +1 to Alistairs suggestion

ac: can we do option 1 then option 2? can we answer the question - we shouldn't delay answering it if we know the answer.

df: this seems like we're potentially creating a back door for more issues and we need to be very aware of this.

<Rachael> draft RESOLUTION: Reject PR and send response; then work on defining web based technology (possibly with W3C) and apply it throughout

<alastairc> I've added my survey suggested response to the thread as a draft: https://github.com/w3c/silver/issues/242#issuecomment-982839687

jb: responding to david's comment - it sounds like it has to be exclusively web-based, and I'd like to talk about this later to understand your concern

<Fazio> seems that way, yes, Judy

<Fazio> I feel like it's a loophole that can be exploited

jb: I think it's very common for working groups to clarify the terms used in their working documents. It would be typical for a group to provide clarification.

<Zakim> janina_, you wanted to support not defining web technologies even though we can use the term

JSa: we might not need to define web technologies unless we want to define something in or out.

<Fazio> iphot can be another example. If you access it via cloud it's web based. If you download photos to internal memory an open via a downloaded app. Technically it's no longer web based

<Fazio> iphoto I mean

RM: should we reject the PR?

<Jaunita_George> +1 keeping it broad will give folks more room to apply it to other technologies and not feel limited -- and give wiggle room to those that are using WCAG as a legal standard

<Rachael> straw poll: 1) Reject PR and send response; then work on defining web based technology (possibly with W3C) and apply it throughout 2) Reject the PR and send a response

<Chuck> 2

<janina_> +2

<Fazio> 0

<Wilco_> 1

<jeanne> 2

<Jaunita_George> 2

<sarahhorton> 1

<GreggVan> I was going to 1

<JF> 1

<ShawnT> 2

<Rain> 1, can live with 2

<GreggVan> 1

<kirkwood> 2

<AWK> 1

<michael> I think you will end up discussing on any event so either

<JakeAbma> 1

<alastairc> 1, could live with 2 (would need someone(s) to work on it)

<Rachael> 0

<laura> 1

<Lauriat> 1, can live with 2

<Judy> 1-ish -- work on *clarifying* web based technologies in the context of WCAG

<ToddLibby> 1, can live with 2

<Raf> 1

<MelanieP> 2, can live with 1

<GreggVan> +1 o judy's comment

<Fazio> Chuck makes a good point

<Rachael> draft RESOLUTION: Reject PR and send response; then explore defining web based technology (possibly with W3C) and apply it throughout

<GreggVan> +1 to exploring -- with W3c

<michael> +1

<alastairc> +1

<janina_> Just concerned it would take us into tangents

<Chuck> +1

<ShawnT> +1

<Wilco_> +1

<Jaunita_George> +1 and willing to volunteer

<sarahhorton> 1 to clarifying

<ToddLibby> +1

<AWK> +1

<Lauriat> +1

<Rain> +1 and +1 to "clarifying"

<Chuck> and +1 to changing to clarifying

<jeanne> +1 to clarifying

<JF> .75 (ref: Judy's concern)

<MelanieP> +1

<kirkwood> +1 clarifying

<Fazio> 0

<Rachael> draft RESOLUTION: Reject PR and send response; then explore clarifying web based technology (possibly with W3C) and apply it throughout

<GreggVan> +1

<JF> +1 to the latest revision

<Judy> +1

<MelanieP> +1

<kirkwood> +1

<Rachael> +1

<jeanne> +1

<Jaunita_George> +1

<laura> +1

<Zakim> Rachael, you wanted to suggested edit to response. Change "digital products that are stand-alone" to "digital products that include more than web based technology"

<ToddLibby> +1

<michael> Yep

<alastairc> https://github.com/w3c/silver/issues/242#issuecomment-982839687

<jeanne> +1 to edit

<GreggVan> +1 to your additional comment / change to response

<Rachael> draft RESOLUTION: Reject PR and send response as ammended; then explore clarifying web based technology (possibly with W3C) and apply it throughout

RESOLUTION: Reject PR and send response as amended; then explore clarifying web based technology (possibly with W3C) and apply it throughout

ACT New Rules https://www.w3.org/2002/09/wbs/35422/act_nov_10/results

<Chuck> no concerns

rm: we'll skip ACT rules and move to WCAG 2.2 as that's more time sensitive.

WCAG 2.2 Target size https://www.w3.org/2002/09/wbs/35422/wcag22-target-size-min/results

Name Change #1871

<Rachael> https://github.com/w3c/wcag/issues/1871#issuecomment-873135394

rm: received a request to change the name back to pointer target spacing.

<alastairc> +1, I couldn't work on the numbers alone.

ac: david's response was good.

mg: it would be a good idea to explicitly state that the SC has been re-written to emphasize target size.

<alastairc> I read Pat's comment as 'can live with'

<alastairc> I added this to David's response: "We re-wrote the SC text to emphasise the size, and spacing is now an exception."

<mbgower> +1

<Wilco_> +1

<ShawnT> +1

rm: how do people feel about accepting mike gower's response to emphasize the target size?

<sarahhorton> +1

<GreggVan> +1

<alastairc> +1

<Rachael> draft RESOLUTION: Accept response with Mike Gower's amendment

<MelanieP> +1

<ToddLibby> +1

<laura> +1

<JF> +1

<kirkwood> +1

RESOLUTION: Accept response with Mike Gower's amendment

Using "should" in the Understanding doc is confusing #1874

<Rachael> https://github.com/w3c/wcag/pull/2021/files

jf: suggests some alternative word-smithing.

<Rachael> Strawpoll: Best if, Prefer, Recommended, Suggest

rm: let's do a quick straw poll on the wording.

mg: it might be useful to come up with some examples so that there are some examples that people can see

<Chuck> I prefer we recommend the suggestion of best if (he said sarcastically)

rm: can we do that for Friday?

<Rachael> draft RESOLUTION: Accept PR and discuss wording choices further on Friday

<Chuck> +1

<ShawnT> +1

<ToddLibby> +1

<mbgower> +1

<laura> +1

<kirkwood> +1

<sarahhorton> +1

<GreggVan> +1

<Rachael> Word option: Best if, Prefer, Recommended, Suggest, Advise

rm: can someone create some examples so that we can discuss them on Friday?

<mbgower> I'll make an issue for it

<Rachael> draft RESOLUTION: Accept PR and discuss wording choices further in a future meeting

<Chuck> +1

<ShawnT> +1

<ToddLibby> +1

<kirkwood> +1

<Rachael> +1

<sarahhorton> +1

<JF> +1

<laura> +1

<MelanieP> +1

RESOLUTION: Accept PR and discuss wording choices further in a future meeting.

<Wilco_> +1

Google feedback #1894

<Rachael> https://github.com/w3c/wcag/pull/2122/files

<Rachael> Response: https://github.com/w3c/wcag/issues/1894#issuecomment-960323246

rm: david mcdonald had a long response for this; I'd like to defer to alastair on this.

<Zakim> mbgower, you wanted to say just change the preamble

ac: I think this is content we've discussed before.

<Rachael> draft RESOLUTION: Accept PR and response as amended

<ShawnT> +1

<sarahhorton> +1

<laura> +1

<alastairc> https://github.com/w3c/wcag/issues/1894#issuecomment-981477882

<Rachael> +1

<ToddLibby> +1

<GreggVan> +1

<Wilco_> +1

RESOLUTION: Accept PR and response as amended.

Minimum Component Size #1870

<Rachael> https://github.com/w3c/wcag/issues/1870#issuecomment-907356155

Adding diagrams that make the reality/consequences of target offset clearer #1848

<Rachael> https://github.com/w3c/wcag/pull/2108/files

<alastairc> Preview link: https://raw.githack.com/w3c/wcag/dbce3c6320e5f0838ce1da6dff0271332de2fcf3/understanding/22/target-size-minimum.html

mg: there's really nice use of figcaptions in the document, but the alt text repeats some of that content. If we can cut down on some of the complexity of the alt attributes and leave the figcaption content, that might make the content easier to consume.

<alastairc> JF - have a look at the page, we have alt and figcaptions.

<laura> +1 to JF

jf: figcaption isn't really adding an accessible name. I want to be really careful about mixing alt and figcaption content.

ac: would this mean adjusting the alt attributes to make them shorter?

mg: if folks think the content is fine then I can live with this.

tl: I can make changes if needed.

<Rachael> draft RESOLUTiON: Accept the PR with the removal of last part of 103 (see survey) and Todd will take a last look at optimizing the experience between alt text and fig caption content

<Chuck> +1

<ShawnT> +1

<ToddLibby> +1

<GreggVan> +1

rm: this is a little more space than we usually give resolutions. are people comfortable with that?

<JF> +1

<laura> +1

<kirkwood> +1

RESOLUTION: Accept the PR with the removal of last part of 103 (see survey) and Todd will take a last look at optimizing the experience between alt text and fig caption content.

<Rachael> +1

WCAG 2.2 Dragging https://www.w3.org/2002/09/wbs/35422/WCAG22-Dragging-movements/results

Adobe Comment on 2.5.7 Dragging Movements

<alastairc> Todd - I've merge your PR, but you can update the branch to adjust the alt text.

<Rachael> https://github.com/w3c/wcag/pull/1961/files

rm: a slider example was asked to be added.

mg: this depends on what you define as a page, whether something is opening in a new window, a dialogue. etc. I wonder if this has to be on the same page or if the mechanism is on the same page.

ca: I think gundala is too narrowly defining what conforming alternate version means.

ac: I don't think gundala's and oliver's assertion holds up. Having an alternative input to something like a color picker is a fairly common approach.

Dragging Movements needs some attention #1917

<Rachael> https://github.com/w3c/wcag/pull/1954/files

rm: there have been edits since last week to address some of the comments made.

<alastairc> Note - MichaelG's PR has been merged into Detlev's version.

mg: I'm concerned that this SC is a little immature in its current state.

<Wilco_> +1

mg: one of the examples given isn't dragging, it's a pointer-based gesture.

<kirkwood> +1

mg: I'm concerned that we don't have research to back this up, we only have assertions. This is a non-trivial change for authors.

ac: I think there's too many changes for this right now.

mg: I think the PR can be accepted, but it doesn't address the underlying problems.

<Rachael> draft RESOLUTION: Accept PR but add issue to give this PR more attention including the challenges that Mgower raises

mg: I think it's important not to confuse people

<kirkwood> agree that path based gestures and dragging issue needs clarity

jf: I'm concerned with accepting a PR when this needs a lot more work

<Chuck> +.5 to john

rm: we're discussing accepting the PR but not closing the issue.

jf: don't we wait until we've discussed this more?

ac: it will help when detlev, the primary author, has updated the document.

mg: I think this improves some of the current wording issues, but I take John's point.

<ToddLibby> alastairc: Just saw your comment. Thank you.

<Chuck> I can live with it.

<Chuck> I agree with John, but I can live with accepting PR.

<alastairc> This is all 'understanding' informative changes.

rm: can the group accept accepting the PR but not closing the issue?

<mbgower> +1

<Rachael> draft RESOLUTION: Accept PR but add issue to give this PR more attention including the challenges that Mgower raises

<ShawnT> +1

<Chuck> +1

<ToddLibby> +1

<alastairc> +1

<laura> +1

<kirkwood> +1

<GreggVan> +1

<Wilco_> +1

<Raf> +1

RESOLUTION: Accept PR but add issue to give this PR more attention including the challenges that Mgower raises.

– DRAFT –
AGWG Teleconference

30 November 2021

Attendees

Meeting minutes

new members and topics

Tip of the Week

Reminders

Writing Testable WCAG 3.0 Outcomes (Wilco 30 min)

WCAG 3.0 Requirements https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/results

Request to change web to digital in Abstract

ACT New Rules https://www.w3.org/2002/09/wbs/35422/act_nov_10/results

WCAG 2.2 Target size https://www.w3.org/2002/09/wbs/35422/wcag22-target-size-min/results

Name Change #1871

Using "should" in the Understanding doc is confusing #1874

Google feedback #1894

Minimum Component Size #1870

Adding diagrams that make the reality/consequences of target offset clearer #1848

WCAG 2.2 Dragging https://www.w3.org/2002/09/wbs/35422/WCAG22-Dragging-movements/results

Adobe Comment on 2.5.7 Dragging Movements

Dragging Movements needs some attention #1917

Summary of resolutions

Diagnostics