AGWG Teleconference -- 08 Jun 2021

<Chuck> Hi Rachael... well, that just answered my q.

<Chuck> I've got 3 regrets, MO most recent.

<JakeAbma_> scribe: JakeAbma

<ChrisLoiselle> Jake, I can take the second hour so it works for you this week, no issues here if that helps.

<Jennie> scribe: Jennie

Introductions and new topics

Rachael: If you are new or have not introduced yourself, would you like to?
... Are there other topics anyone would like to make sure we address in the next few weeks?

Bruce: I would ask we do an informal check on what people think it is going to be by the end of the calendar year

Rachael: OK conversation about the timeline for WCAG 3

Chuck: The initial form of publication?

Bruce: yes

Rachael: any other topics?

CFC update on Heartbeat publication

Rachael: WCAG 3 heartbeat publication - next working draft.
... It did pass on Saturday. Any questions or concerns?

Introduction to WCAG 3.0 explainer https://w3c.github.io/silver/explainer/index.html

<david-macdonald> presnt+

Rachael: The explainer will be published as a separate note.
... We will send out a survey later this week and discuss in more detail next Tuesday

Jeanne: We had previously voted to move some information into the explainer.
... When we publish the Heartbeat, the link will be to the explainer editor's draft
... The idea is to publish the explainer as a working draft of a note - not normative
... For the 3rd quarter heartbeat (hoping to be in August)
... This will be updated based on comments
... Then after updating it will go into the editor's draft

<jeanne> https://w3c.github.io/silver/explainer/#background-on-wcag-3-0

(link to the explainer)

Jeanne: Technical Architecture team has a template they recommend for explainers
... They have a structure.

<ToddLibby> I'm irc only today (staff mtg)

Jeanne: The purpose of an explainer is to show the decisions and background behind technical documents. The example they give is API
... They want to know scenarios, tricky design choices
... I think this will be helpful as we work more on conformance.
... There was an earlier draft - I moved this into the template
... If anyone has comments about the introduction, please email me about it.
... Key things from the explainers:
... They want the user facing problem that needs to be solved, example code...(reads from the template)
... This is going to be a good place to capture a lot of the conformance decisions

<jeanne> the user-facing problem which needs to be solved;

<jeanne> the proposed approach to solving the problem;

<jeanne> the way the proposed solution may be used in practice to address the intended use cases, via example code;

<jeanne> any other venues (such as mailing list, pull requests or issue threads external to the location of the explainer) where the reader may catch up on discussions regarding the proposed feature or features;

<jeanne> the alternatives which have already been considered and why they were not chosen;

<jeanne> accessibility, security and privacy implications which have been considered as part of the design process.

*Thanks Jeanne!

Jeanne: We did a background and development history going over the process we took
... (reads from the draft explainer)
... Then in the background section we link to the research summary slide presentation, gave some of the early goals.
... Next they want the goals for the project
... We took a few key goals from the Silver requirements
... goals for inclusion of more people with disabilities
... Then Goals for Content came primarily from the (scribe missed this) document
... Goals for Conformance: I would like to have a conversation around the goals for conformance
... The Non-Goals - they want to have included what is out of scope
... I added non-web emerging technologies and normative requirements for platforms, operating systems, software in the web technology stack
... We are not writing for ATAG and UAG
... We are writing informative information that will help authoring tool and user agent, including AT, help them know what will best help
... support people with disabilities
... but it is not normative for authoring tools or user agents
... Explanation Behind Decisions: includes all the information about the difference with 3.0
... I would be open to hearing any suggestions
... Section 6 is the design sprint from 2018 - the problem statements and the suggestions that came out of the design sprint
... They are very interested in knowing if we got broad public input.
... In 2018 we had feedback from CEOs, usability professionals, experts in W3C standards group - a good mix of stakeholders
... Then an appendix with references

David-MacDonald: Thanks for the hard work on this.

<Rachael> https://w3c.github.io/silver/explainer/#background-on-wcag-3-0

David-MacDonald: Early on in the document it says (reads from document) - sounds like we are removing a normative requirement and replacing it with non-normative

<bruce_bailey> > Remove “accessibility supported” as an author responsibility, and help developers of authoring tools, browsers, and assistive technologies learn the behaviors that users expect of their products.

David-MacDonald: We are basically saying we are going to remove a requirement and add a suggestion to fix it
... I'm wondering if there is something we can do about that.
... I also don't see where it explains the cost of accessibility more manageable and easier

<bruce_bailey> https://w3c.github.io/silver/explainer/#ConformanceGoals (3rd bullet from end of list)

David-MacDonald: I know a lot of companies feel this burden

*Thank you Bruce!

David-Macdonald: Lowering cost and improving functionality could be one area we explore
... The document uses the word "needs to do" and I am wondering if "need to do" is more of an imperative
... I'm not sure if we have that power over those stakeholders

Jeanne: Thank you David
... Should we have more goals for inclusion?

<Lauriat> WCAG 3 Requirements, for reference: https://www.w3.org/TR/wcag-3.0-requirements/

Jeanne: We took these goals from the requirements
... (reads from 3.1)

"Actively recruit a diverse range of people with disabilities in recognition of the importance of their contributions to accessibility standards and solutions. Review and monitor whether people are included. Continually evaluate inclusive features of available tooling and procedures. Facilitate global participation and feedback."

<Zakim> Rachael, you wanted to state that I'd like to consider including younger participants

Rachael: I wonder if we want to consider younger participants and make that a goal for inclusion
... We discussed this 2 TPACs ago
... I'm talking about emerging accessibility experts from younger groups

<johnkirkwood> Diversity goals should be included, no?

Jeanne: What a great idea.

<Ben> How old is young?

<Fazio> Now I'm questioning my youth :(

Rachael: (reads the comments above) and I just wanted to see if it goes in there
... Any other questions regarding inclusion?

Katie: I'm working if Greg V had weighed in on anything?

Jeanne: Not on this document

Katie: I would go to the participants guideline working group

<david-macdonald> The document is proposing to remove "accessibility supported" from authoring requirements, and replacing it with "recommendations" from UAAG, ATG for user agents and Authoring tools. We don't have jursidiction over those stakeholders, only over authors so I'm reluctant to remove accessibility support.

rachael: other questions around the goals for inclusion?

<david-macdonald> COuld we add something about lowing cost of accessbility and not increasing testing burden

Jeanne: We have a lot of goals for conformance
... Some of these are conflicted

<johnkirkwood> I would want to see more standard DEI Diversity Equity and Inclusion goals incoropotated.

Jeanne: David is adding in other goals - I think that is definitely something we should put in a survey and decide if that should be a higher priority
... I wanted to give people an opportunity to say there are particular ones that should be removed or added

Rachael: I think if people have an idea of ones they want removed we can add those to the survey, or we can survey generally

Jeanne: I would like to get this document approved within the next 2-3 weeks so we can say it will go into the August heartbeat

MBGower: I do 2nd David's request about accessibility support
... I do think it is an important question. I hope it can be brought into the discussion some other time.

Jeanne: It is a challenging discussion. A group worked on it in the Silver Design group
... One recommendation came out not to have normative requirements for those groups
... There was resistance from legal departments
... We wanted to move forward with it, but we didn't want to trigger opposition
... That was the solution that came out of the design sprint, but we have never had that conversation so it would be a good one to have

<Zakim> mbgower, you wanted to say I mean author requirements for accessibility supported

Jeanne: either before we publish the explainer, or take it out of the explainer

<jon_avila> I agree accessibility support is important and is not tied to authoring tools or user agents.

MBGower: I'm not talking about user agent and AT scope. I'm talking about the author requirements
... If we are removing any mention of ATs and user agents out of this - I don't think we want to remove the part that authors have a responsibility

Jeanne: This is a tough one.
... That was the pre-cursor to the solution. Accessibility supported came up in Silver research often as a problem
... Companies were often choosing between accessibility standards and accessibility supported
... There were known bugs that were not being supported by the assistive technology vendors
... We could write up cases that were brought up
... That's part of the problem we were trying to solve
... How do we resolve conflicts between the standard and the AT
... Our solution was to take it off the author, and put it on the AT and the other tech (like OS, authoring tool conflict, browser conflict)
... I know Makoto had several examples of Japanese screen readers that in 2018 did not support ARIA at all

<Zakim> Lauriat, you wanted to say we can (and should) write up more details around how the new conformance model can help with some of this

Lauriat: it is not something we have to solve here, but we can and should write up details about how the new conformance model can help with this
... So that way we can help people understand what will make things accessible
... when there are gaps and bugs there

David-Macdonald: I am thinking about the intention of accessibility supported - maybe this is a gap we can fix in 3.0
... We wanted to give authors more flexibility
... When we don't have ways to do something now, as long as you can do it with AT it is fine
... The intention was not to let AT off the hook

<ChrisLoiselle> Reference points on discussions: https://www.w3.org/TR/wcag-3.0/#only-accessibility-supported-ways-of-using-technologies and https://www.w3.org/TR/WCAG21/#cc4 are reference points for the accessibility supported conversation .

<ChrisLoiselle> On https://www.w3.org/TR/wcag-3.0/#about-wcag-3-0, there is an editor's note on Future drafts of the guidelines will include additional examples of ATAG- and UAAG-related content. On content authors, item 3 Allow for bugs and oversight by content authors, provided the impact of them is limited to users with disabilities.

<alastairc> Hmm, making the WCAG 3.0 guidelines more outcome-oriented doesn't solve the problem that accessibility-supported was intended to solve. We do need to re-assess that aspect as we work on the scoring/conformance.

David-Macdonald: Maybe instead we say we want to modify accessibility support to retain its original goals - to allow authors to use far reaching technology
... There maybe something we can do
... If there is something new - you would be responsible for accessibility support - that may help address this

Rachael: It sounds like this is definitely a discussion that we need to have, so we can add it to the survey

Katie: We want to teach and encourage
... We want authors to be aware that some tools support, others do not
... AT and browsers - all user agents, being able to support those APIs. I would be concerned about not adjusting this somehow.
... AT vendors have a lot of pressure. They don't have the money the browsers have
... They try to keep up with changes in the spec

<mbgower> Beyond Alastair's comments (which I agree with) there is also the whole challenge of how to report something that works without an AT then fails with an AT. Again, could go on at length about this but I feel we're off topic from the Explainer document review. As long as it is captured to further discuss.

Katie: I would not frame them as the bad guys
... I think they need additional support

<Makoto> Accessibility support is important especially in countries/regions where popular ATs are not good enough to support new specs like WAI-ARIA. In Japan, we used to crate test files and test them with ATs. It was really tough and challenging.

Jon_Avila: I don't see this as a larger issue in the space
... We do 100s of audits every year. I don't see this as such as large issue
... I can't speak to other markets
... I think there is a misunderstanding - it is about creating things in a way that are supported by standard AT
... If we remove it - people can say I put the accessible name in, if you cannot read it, that's a problem
... I do think that there is a relationship to the methods and techniques
... The methods will, in the future, look for things that are known to be accessibility supported
... This will be addressed at some level
... If people are using AT we will run into it at the test level as well

<Zakim> jeanne, you wanted to talk about the research on accessiblity supported

Jeanne: I want to say the interpretation that we heard from people in the research is that people do interpret it to be that they need to make it work even if there are bugs in the AT
... That's what the people responding to interviews or survey said
... I think it is a problem that we need to talk about

<KimD> +1 to Jeanne's recall

Jeanne: The suggestion that came from the design sprint was a more inclusive approach
... It seemed like a better approach to look at it holistically
... I think this would be a good thing to talk about for the future
... For this draft: we will put together a survey, and send it out.
... I will gladly accept pull requests and suggestions. I would prefer not to get issues.
... we will move forward on this next week

Reporting in 3.0 discussion

Rachael: Mike Gower had requested this topic in a previous meeting
... in WCAG 2x we don't directly address reporting
... I think we will come back to this

Mike Gower: In WCAG 2x the reporting on compliance is sort of farmed out to the existing VPAT standard

scribe: There is 5.2 but it is difficult to consume, and it doesn't specify
... In Silver we have a different approach
... In 2x A, AA, AAA tells you which to report against
... In Silver - it is a composite, and discusses how well you meet them
... For 8.6 there are conformance claims and states what you have to report
... You have to specify the guideline, the version, if the conformance level is satisfied
... Then a concise description such as a list of URIs
... Thinking about this in terms of state changes
... Then the technology used to test the claim
... By practice, some people do this to the preface of the VPAT
... But you are left to decide if you want to do this. I think this is good to have this
... I think the Concise Description piece came up in a discussion a few months ago
... There might be a lot of discussion around what this means
... There is also the manner in which people do reporting
... We will have to iterate how prescriptive to be, to get towards the goal
... You need to either confirm or contest that

<mbgower> https://www.w3.org/TR/wcag-3.0/#conformance

<ChrisLoiselle> https://www.w3.org/TR/wcag-3.0/#required-components-of-a-conformance-claim and https://www.w3.org/TR/WCAG21/#conformance-reqs

Mike Gower: My 2nd point: how testing changes between 2x and 3

scribe: There are automated testers

<jeanne> https://w3c.github.io/silver/guidelines/#conformance-claims

scribe: If someone says they pass 2x - if it comes back with no failures, you have some certainty
... If you run the automated test and it fails, if they are claiming conformance, at least you have automated tests that confirm or dispute the claim
... When you move to 3.0 you don't have to pass everything to have a conformance claim
... Where you identify some problems, it doesn't help you determine if the claim is accurate or not
... I think we need some more direct discussion about what constitutes conformance

<Lauriat> From WCAG 2.x: "A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim."

scribe: To help testers and others to assess that claim

<Zakim> Lauriat, you wanted to say we largely copied WCAG 2.x on how to construct conformance claims, that "concise description" in particular comes from WCAG 2.x, we tried to focus more

Lauriat: In the conformance claims section, we tried not to reinvent that wheel and copied what is in 2.X
... We were aiming to change the unit of measurement from webpages to something that worked to web apps and other bits of technology
... I'm not sure how it introduces much of a difference from the issues we currently have
... We have no intention of making things more difficult
... We actively want to support automation whenever possible both today and in the future

<bruce_bailey> from: https://www.w3.org/TR/WCAG22/#conformance-required

<bruce_bailey> A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim.

JF: Mike, thanks for bringing this up as it is critical to the larger discussion

<JF> https://www.w3.org/WAI/standards-guidelines/earl/

JF: This is a W3C specification
... Shadi was much involved

<Detlev> EARL = familiar, but very rarely used in practice?

JF: It allows a standardized reporting format
... It is really broad
... If we had a standardized format that uses EARL we could link this to the product being evaluated
... This could link to this standardized report
... It is not just a simple pass or fail - a 70%, or 80%; or a 3 or 4
... This would be a mechanism that would allow something like that
... This would have us ask more of authors
... I'm not sure if this is the right way forward, but I have been thinking about it a lot

David-Macdonald: When I look at the section on conformance claims it looks familiar. So I agree with Shawn
... I think what Mike is saying it is because of what the goals are for WCAG 3 it will be harder to test automatically and hard to make a conformance guesstimate
... I think the discussion goals back to where do we draw the lines that will make things that are practical
... I think it is a broader discussion than just conformance statement
... And is testing part of this discussion?

Rachael: I think we want to focus on reporting but will defer to Mike

Mike Gower: I think testing will have to come into this because you are reporting on the results of your testing

scribe: We do want to keep the topic from getting too big

Mike: the reproducibility: how do you confirm it?
... Or how do you disagree with someone's conformance claim

<JF> +1 to Mike "Testable, Measureable, **Repeatable**"

<Zakim> jeanne, you wanted to say that there is a mis-conception about the automated testability of WCAG3. Even the new guideline has automated tool

Mike: I think we want enough information that someone can claim gold and not be asked to show proof

Jeanne: I want to correct the misconception that WCAG 3 will be less testable
... 4 guidelines came from WCAG 2
... That's the way they are tested today
... The new guidelines: we created automated test tool
... Not everything will be automated testable
... We are certainly not going to be automatically less testable

David-Macdonald: I am confused by saying it will be as much testable, since we are changing some pieces for a good reason, but we removed testable and moved towards measurable

<Lauriat> -1, we will make it testable, otherwise we couldn't measure the results of the test.

<jeanne> We only removd Testable from the Requirements. We have tests in every Method.

David-Macdonald: I think without automation, we shouldn't have human testers documenting more administrative things
... It is more expensive
... Let's count things that are done properly but count them automatically

<Zakim> JF, you wanted to comment about testability and subjectivity

JF: Yes, we are making things testable. The concern I have is the consistency or repeatability of the results ...Example: need for plain language

<KimD> https://www.w3.org/TR/wcag-3.0/#outcomes-structure:"Outcomes are written as testable criteria and include information on how to score the outcome in an optional Conformance Claim." ...Example: I'm not sure how I can consistently get the same results for using plain language
... You can't use plain language for writing a dissertation on nuclear physics
... The results are going to be more subjective
... If Mike Gower makes a claim on something's conformance, I should be able to get the same results

<Zakim> Lauriat, you wanted to answer the reproducibility point, in that we want transparency through conformance claims made to promote that. We can't keep people from lying, but we can

Lauriat: WCAG 2 already has subjectivity
... We are just trying to make a way to express that to enable more consistent results
... We share the same goal
... Re reproducibility: for the conformance claim itself
... We want to promote reproducibility
... We can't stop people from lying about conformance

<david-macdonald> 6.2.2 Conformance Design a conformance structure and style guides that shift emphasis from “testability” to “measureability” so that guidance can be included that is not conducive to a true/false test. True/false tests can be included, but they are not the only way to measure conformance."

Lauriat: We want a structure for people to more transparently make a claim

<JakeAbma_> scribe: JakeAbma

*Many thanks Jake!

<Zakim> jeanne, you wanted to say that more reporting can be less efficient and increase costs

<JakeAbma_> Jeane: Love EARL but it will increase cost

<Zakim> JF, you wanted to note that the more granular we make reports, the easier it is to keep "updated"

<JakeAbma_> Jeane: we don't want different reporting mechanism around the world

<JakeAbma_> JF: EARL reports can be a click of a button

<jeanne> And how does the local pizza shop pay for a tool that could generate EARL reports?

<JF> @Jeanne - an "Earl Producing tool" could live at the W3C (similar to the W3C Validator tool)

<JakeAbma_> Jennie: governments might not want to adopt if test results are not accurate, get the same results

<JF> +1 Jennie

<JustineP> +1 Jennie

<johnkirkwood> +1

<JakeAbma_> Jennie: consistency and repeatability is needed

<JakeAbma_> MG: process as a measure, instead of outcomes, might be a good way to look at products

<jeanne> +1 to documenting process. Maturity model presentation is next week addressing this

<JF> https://www.plainlanguage.gov/guidelines/

<JakeAbma_> JF: working on proposal, reward for protocols, similar to the process idea

<bruce_bailey> Also see: https://www.plainlanguage.gov/law/

Making Content Usable for People with Cognitive Disabilities (that JF referenced): https://www.w3.org/TR/coga-usable/

<Lauriat> Thanks, Bruce! Helpful reference I keep forgetting about…

<JakeAbma_> JF: EARL report can support protocols... in the conformance mix

<mbgower> Breakout group?

<Zakim> Lauriat, you wanted to propose building up tests, guidance, and data on how well (or not!) it works

<JF> +1 Shawn

<JakeAbma_> SL: concrete tests / examples will make it more insightful

<Chuck> +1

<Ben> +1

<Detlev> +1

<JakeAbma_> +1

<Rachael> proposed next steps: Gather more tests, etc then revisit in1-2 months to see if a subgroup can work on it

<JustineP> +1

<Makoto> +1

<johnkirkwood> +1

<mbgower> Thanks for the discussion. It was useful, to me

<Rain__> +1

<Jaunita_George> +1

<jeanne> +1

<Ryladog> +1

<Lauriat> +1

<laura> +1

RESOLUTION: Gather more tests, etc then revisit in1-2 months to see if a subgroup can work on it

WCAG 2.x issue resolutions https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/results

Error Identification slightly unfocused/mixes up various concepts #977

<Rachael> https://github.com/w3c/wcag/issues/977

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

<JakeAbma_> AWK: my concern is that this update seems to suggest that all errors need to be described in text directly on the page and not in alternative text on an image

<bruce_bailey> +1 to AWK, alternative text can meet 3.3.1

<alastairc> Yes, would meet (although can be problem for other things)

<Detlev> +1 if it is very conventional

<david-macdonald> +1 bt bad usability

<Ryladog> not for sighted cognitive user

<Ryladog> icon is not enough

<Ryladog> needs text

<Rachael> " If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text."

<Ryladog> +1 to MG and AWK

<bruce_bailey> +1 to MG, that crappy alt text is not enough

<mbgower> Okay, on same page with AWK

<Ryladog> visible text is needed too on top of programmatic

<Ryladog> +1 to David, exactly!!

<JakeAbma_> DMD: icon is not enough, it's not text for all users

<Rain__> +1 to David

<Rachael> JakeAbma_: I think patrick also made this PR request. First it says the item is identified and second is that it is described. We have notes that it is identified in text and explained in text. It can be both.

<david-macdonald> +1

<Rachael> ...the description in text can be the identifier so you don't need an icon. You can have an icon as the identifier and text as the explanation. It isn't clear in the text or understanding document. Also here, different people have different views.

<Rachael> ...Patrick created some examples. Only providing an icon is enough in some cases but not in all. Only providing text is enough in some examples. Responding to what Andrew said, if its alt text, only a selection of users can get it. We have different views of it. Can we get unanimous agreement on what the statements mean? If for all users, must be on the screen.

<Rachael> ...What was meant by the authors. That woudl be a good starting point. The other issue was what Andrew said. Its error suggestion.

<Rachael> ...So Does someone remember what was the intent?

<JakeAbma_> DMD: it was primarily for SR users, described in text...

<JakeAbma_> dmd: now we want it close to the field etc.

<bruce_bailey> > sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

<AWK> I can confirm my recollection from WCAG 2.0 development which is that alternative text counted as text and that was understood for 3.3.1. Also agree with Katie that alternative text is not just available to SR users.

<Zakim> bruce_bailey, you wanted to say my clear recollection is that "error is identified" is one requirement, and "described to the user in text" is second requirement.

<JakeAbma_> BB: yes, it was primarily for SR users, and text meant flexibly

<mbgower> https://www.w3.org/WAI/WCAG21/Understanding/error-suggestion

<JakeAbma_> KH: I remember it was for all people, not only SR

<AWK> Exactly @bruce - there is no text associated with a CSS style change to make a bounding box red.

<Zakim> alastairc, you wanted to ask about a small update to the PR

<alastairc> "And, to ensure that the information is available to all users (whether they are using assistive technologies or not), the error messages must be provided as visible text."

<bruce_bailey> odd that "text" is not hyperlinked to glossary in that sc

<Chuck> The last sentence is: And, to ensure that the information is available to all users (whether they are using assistive technologies or not), the error messages must be provided as visible text.

<bruce_bailey> https://www.w3.org/TR/WCAG22/#dfn-text

<alastairc> "Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred."

<AWK> what line numbers Alastair?

<Chuck> +1 to Alastair's suggestion

<Zakim> mbgower, you wanted to say the background helps exaplin 3.3.3

<AWK> not sure about line 101

<alastairc> Line 101 replicates the SC text, so should be ok. Could extend to "text or alt text"

<JakeAbma_> KH: we used to submit the whole form, now we check on the page, that was the reason we had 331 and 333

<bruce_bailey> Also, 3.3.3 is AA and 3.3.1 is A

<JakeAbma_> DMD: 3.3.1 was for identify, 3.3.3 how to fix it

<alastairc> https://github.com/w3c/wcag/pull/1651/files

<mbgower> " And, to ensure that the information is available to all users (whether they are using assistive technologies or not), the error messages must be provided as visible text."

<Rachael> proposed: Remove changes from lins 22 and 23 and line 113 and then move it forward.

<Chuck> § PROPOSAL remove lines 22 and 23, and update line ### to read "Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred."

<bruce_bailey> 3.3.3 fixing is definately additional work over 3.3.1 of knowing there is a problem

<alastairc> https://github.com/w3c/wcag/pull/1651/commits/5920a572d90b6db0e53a08428f0276d85fb9686f

<alastairc> Changes to the PR ^

<Chuck> Jake: I haven't seen the adjustment. Can you enlighten us and tell us with your adjustment, what is needed for identification for text? Is alt text enough?

<Rachael> JakeAbma_: I haven't seen the adjustment yet, but can you tell us what is needed for indentification. Is alt text enough? Can the alt text serve the same purpose?

<Chuck> Jake: Or text that serves both?

<Chuck> Alastair: Yes, link at 37 past. Just removing last sentence of first paragraph. Second modification is to make available in text or alt text. And reverting change from PR for benefits, changing users to blind and color blind.

<AWK> No, not yet

<JakeAbma_> RM: accept changes and continue discussion?

<JakeAbma_> AC: yes

<JakeAbma_> AWK: also 4.1.2 was related to this PR

<AWK> The error messages must be sufficiently descriptive to help users understand what the problem is.

<Rachael> The error messages must be descriptive to help users understand what the problem is.

<JakeAbma_> KH: do we separate disability groups?

<alastairc> There is a link to 3.3.3 in the understanding, haven't assessed whether it is sufficient.

<sarahhorton> +1

<Zakim> bruce_bailey, you wanted to replace "alt text" with something else

<JakeAbma_> KH: doesn't seem appropriate to focus on visible Vs. programatic determined text

<AWK> it isn't hyperlinked because it isn't the first instance.

<alastairc> "in text or a text alternative."

<JakeAbma_> BB: 3.3.3 is probably more suitable for cognitive but doesn't mention text

<mbgower> Mine is related, for sure

<bruce_bailey> @AWK you think we only hyperlink the first instance ?

<Zakim> Ben, you wanted to suggest that we could explain that text includes alt text

<JakeAbma_> BT: linking to glossary is important

<JakeAbma_> BT: maybe mentioning alt text is acceptable

<johnkirkwood> +1 Katie

<JakeAbma_> KH: the criterium is about identifying text for all users, so alt text is not enough

<sarahhorton> +1 Katie

<Ben> +1 to Katie

<Fazio> +1 AWK

<JakeAbma_> AWK: I agree about users needing the text, do not think that is what it says

<bruce_bailey> +1 to what katie is saying about 3.3.1, that icons (with alt text) might not be enough for coga issues, but +1 to AWK that we should not change SC

<Fazio> goes to personalization

<bruce_bailey> i don't remember 3.3.1 being aimed at coga issues

<JakeAbma_> AWK: cognitive needs may be diverse, so also people who do not want all text on screen at once

<Fazio> AWK makes solid points

<Zakim> mbgower, you wanted to say this in the pre-existing version, is confusing "It is perfectly acceptable to indicate the error in other ways such as image, color etc, in addition to

<JakeAbma_> AWK; we only refer to glossary once

<bruce_bailey> @AWK there are plenty of redundant links to glossary terms

<AWK> @bruce - ok. That wasn't my understanding of the approach, but it is easy to see how issues could creep in

<david-macdonald> That's my understanding of original intent back in the day

<Fazio> that would be redundant

<bruce_bailey> see: https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-identified.html#minimize-error-identified-intent-head

<Fazio> no need for redundancy

<Zakim> Rachael, you wanted to ask what we mean by "the item that is in error is identified"

<mbgower> There is going to likely be a way to fail any problem between the 2 SCs, which is why I think this hasn't been such a problem until now.

<bruce_bailey> mentions screen reader, nothing about coga

<JakeAbma_> RM: if 3.3.1 is only about an error, comfortable with icon and alt text

<Fazio> +1 Rachael

<Rain__> +1 Rachael

<bruce_bailey> further down:

<bruce_bailey> This Success Criterion may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.

<Fazio> the error isn't important. the indtructions to fix are

<mbgower> Visual examples would also help

<Zakim> AWK, you wanted to say that 3.3.1 is not just about "there is an error". 3.3.3 is suggesting specific fixes to errors.

<JakeAbma_> q_

<alastairc> double A?

<Chuck> double a

<Fazio> doesn't built in autocorrect do that already?

<ToddLibby> 3.3.3 is AA, yes

<AWK> yes, I agree that 3.3.3 has the suggestions

<alastairc> The error can be indicated in <a>text</a>, which does allow for visually apparent images or icons with suitable alternative text. <a href="error-suggestion">3.3.3 Error Suggestion</a> covers...

<Zakim> Chuck, you wanted to suggest we create new question and review Alastair's proposal next week

<mbgower> Lines 77-78 of the new version includes 4.1.2

<Chuck> +1 should NOT be included

<Ben> not include

<JakeAbma_> not include

<mbgower> 0

<bruce_bailey> not include

<Ryladog> +1 nt include

<AWK> +1

<JenniferC> not include

<JustineP> not include

<laura_> +1 not include

<Rain__> +1 not include

<Detlev> uncertain

<mbgower> I was thinking about aria-invalid

<alastairc> https://github.com/w3c/wcag/pull/1770/files

<JF> Gotta dash - bye all

<alastairc> https://github.com/w3c/wcag/issues/930

- DRAFT -

AGWG Teleconference

08 Jun 2021

Attendees

Contents

Introductions and new topics

CFC update on Heartbeat publication

Introduction to WCAG 3.0 explainer https://w3c.github.io/silver/explainer/index.html

Reporting in 3.0 discussion

WCAG 2.x issue resolutions https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/results

Error Identification slightly unfocused/mixes up various concepts #977

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output