New members and topics

scribe+ dan_bjorge

<scribe> scribe: dan_bjorge

Rachel: Welcome, DJ, to the group!

DJ: I'm the digital accessibility specialist at northwestern university college. Excited to work at WCAG!

Announcements

<Rachael> https://www.w3.org/2023/09/TPAC/registration.html

Rachel: TPAC registration opened last week. Information is at link in chat

<Rachael> https://www.w3.org/2023/09/TPAC/schedule.html

Rachel: schedule is also available. Will be meeting informally mon/tue, encourage folks to join in hybrid if not in person, will have more informal working sessions thu/fri because of the holiday
... everyone can participate, but will be working on moving wcag 3 forward then

Shadi: Clarifying: is it mon/tue, or thu/fri?

Rachel: Meeting for decision making on mon/tue, more informal working sessions on thu/fri

<Ben_Tillyer> I'll be there Mon-Thurs :)

Guidance for policy makers mid-point presentation (30 Minutes)

Rachael: Shadi will be presenting from our guidance for policy makers subgroup

<shadi> https://docs.google.com/presentation/d/1y_uNtKFOrvVmtVgDmqWTHe_vsLwTfXYBJQ39un6UKNE/edit#slide=id.p

Shadi: Thank you. I'm pasting slides into IRC for folks to follow.
... This is the guidance for policy makers subgroup.
... Objective of this group is to explore the previously published "use cases for WCAG 3.0" document (linked from slides).
... Has small examples, use cases, scenarios in which achieving full conformance is maybe infeasible or difficult.
... Want to emphasize: not about finding exceptions or exemptions to the WCAG conformance model, but about trying to identify ideas for WCAG 3
... Want guidance for policy makers trying to adopt WCAG for cases where issues might not be resolvable via WCAG or any other conformance standard
... Instead of trying to solve everything through WCAG conformance, can we think beyond WCAG as a technical standard and think about other areas
... Prior work: "Use Cases for WCAG 3" document linked from slides. Encourage folks to read through that.
... Despite best efforts from past WCAG work and subgroups, there are still complex problems. Bugs that can occur in any content, issues based on who owns which content, content that is very rarely used, etc
... Aim is not to talk about wholesale exemptions; just to acknowledge that there are scenarios in which, despite best efforts, you'll still end up with issues.
... So how can we improve the current situation and try to move forward?
... Intent of this effort is to explore each of the examples and scenarios from earlier slides and think about what we can do beyond just WCAG.
... How can informative guidance - best practices, guidance, etc - help resolve issues?
... WCAG already has many accompanying resources from WAI - understanding docs, etc - that go along with WCAG
... Finally, how can policies do better than just saying "do WCAG"?
... That puts the responsibility downstream on WCAG and WCAG conformance to resolve all these issues that might not be resolvable using WCAG or any technical standard
... We also want to improve our own understanding of technical conformance vs legal compliance.
... Gregg might call it "the ruler and the rule"
... We often confuse these things (WCAG vs legal conformance)
... It's beyond the scope of W3C to be writing any policies, but when policy-makers are adoption WCAG, we want to give them some consideration
... What can we build in? Some policies have things like "reasonable accomodation" or organizational responsibilities that go beyond WCAG
... The approach of this group is two phased
... Phase 1, the current phase which we're closing right now, is to review these situations, go through them all 1 by 1, and ask how technical standards, informantive guidance, and policy considerations help for each
... 8 weeks for phase 1 is, of course, very short. Not enough time to get deep consensus for each, was more brainstorming; some ideas we ended up with are definitely still controversial because of the short phase timeline. Just wanted to see what ideas might exist.
... In the next phase, if the group thinks it's a good idea, would like to consolidate some of this brainstorming and end up with a potential outline of what such a guidance document would look like.
... Again, given that we're only going to have a few weeks to do this, we're not expecting a solid proposal so much as a sketch. We'd want to come back to the group after that and present to the group, decide if it's useful to continue.
... From this brainstorming - again, far from consensus - we observed some recurring patterns already
... One of the repeated ideas was some form of "protocols". A term used in some other subgroups, also known as "Organizational practices"
... For example, there will always be bugs, but can you publish what your response is when someone reports a bug? How long it takes to respond? What happens with reported issues? If you can't make all content immediately accessibile, what's your prioritization strategy?
... Another recurring idea: The role of authoring tools and more generally, authoring support
... For example, when publishing content, to have tools (maybe web-based tools), flag accessibility issues
... This includes both end users but also tools used to create other websites
... Checking code, not just user-generated content
... Another idea was mechanisms for end users to report accessibility issues. Sure, you have a process for responding to issues, but how do I report them in the first place? Came up in several situations
... Another repeated theme: Not just a technical issue. Is really about organizational culture and processes. What do you do when you find out about bugs. What is your plan for integrating accessibility. Maybe related to maturity model discussions from other groups. Not strictly "check off these boxes and you're done" - seeing accessibility as a cultural aspect.
... Lastly, reinforcing that accessibility still requires combination of automated, human/manual, and process aspects.
... Next step: want to bring the brainstormed ideas together, at least the themes bubbling up, and think about how it could be structured into a "guidance for policy-makers" document
... Want to start with a sketch of such a document, then later dig further back into more detailed examples based on whether group feels it's looking valuable
... There are some open issues/PRs on GitHub and a written word doc from Gregg for example on the original use cases document
... At the end, we'd want to report back to AGWG and discuss outcomes and next steps
... We've had 5 meetings so far; we'd like to ask chairs to extend 3 weeks to 24 July. This here today is an interim report.

<GreggVan> reasonable to expect that the next day the newly acquired site will be accessible. As to allowances for the number of errors or the time before they should be resolved, these are policy issues and not questions of whether a site ia accessible or not. To help provide guidance or thoughts from the WCAG working group a document "Policy Guidance for using WCAG" has been prepared"

Shadi: there is some debate how deeply to dig into each examples, but estimate it would take more like 15-20 weeks to go deep into each example and get consensus. Want to decide whether to do that vs start at a higher-level thing and defer decision on whether to go deeper.

<Zakim> GreggVan, you wanted to say and to say "There are times when web content may fall out of conformance or have spots where conformance fail (e.g. bugs). In a conformance claim a

Shadi: The subgroup page linked in the slides has more details and a list of members, thanks to those that have participated!

Gregg: Thanks Shadi and the whole group for working on this.
... I'm a little confused - I think you said this is a pilot subgroup, which seems good, but then you talked about conformance, which seemed like a big difference.
... These are really great examples of problems, but they're all policy problems.
... We're supposed to be determining whether something's accessible or not, *not* whether someone needs to make it accessible or not.
... If a site has issues, they might need time to make it accessible, but it's still *not accessible*. Separate concerns.

<laura> +1 to Gregg

Gregg: Conformance might need to be able to say "there are these bugs", but that needs to be different from claiming a site is accessible or not
... Think if we stick to talking about policy recommendations instead of bending definition of conformance, think we can get there and on a shorter timeline.

<jeanne> -1 to Gregg, three are problems that can be helped with WCAG3. We should not dismiss it categorically.

Gregg: Shadi: Agree with you, Gregg. This idea about "protocols" - maybe this can come up in a requirement. Maybe one of the WCAG requirements is that your site needs to talk about how it's going to respond to issues. Maybe an authoring requirement might be "when a user types in something, it's checked for accessibility".

Shadi: We're definitely aligned. Do see a relationship between... maybe there are hooks or explanations we can put in WCAG to get an interplay between guidance document and WCAG itself

<Chuck> lost audio?

DJ: I think these are all great observations. Think it might be useful - <disconnected audio>
... Along the lines of having a mechanism for reporting accessibility issues, we should consider a mechanism that's consistent across all sites. Maybe some equivalent of SECURITY.txt but for accessibility

Shadi: To clarify, you mean ensuring that there's an accessibility mechanism to identify how to report accessibility issues?

DJ: Yes

<laura> Guidance for policy makers Scratchpad: https://docs.google.com/document/d/1B-qfTrPxnhIa0AxhPEF6SIDTLAGnneoauBRHGzS5q7U/edit#heading=h.s0ukjtq0hqao

Shadi: We have all the information recorded in a scratchpad document linked in IRC. We're brainstorming in comments on the document. Feel free to review this even if you're outside the subgroup.
... Thank you very much!

Removing Decision Policy https://www.w3.org/2002/09/wbs/35422/w3c_decision_policy/results

Shadi: Feel free to email me to reach out for more questions, you can find it in the mailing list

Rachael: Context and background on removing decision policy: Last week we talked about modifying it, but several folks supported idea of just moving to the default W3C decision policy

<Rachael> Diff: https://github.com/w3c/wcag/pull/3242/files#diff-e19e5d82f2e308431ac84b30853bbe67ac9280a70f8d86d8e5f19b018d648fe1L20

Rachael: We took a week to put together enough info for folks to review that and think about what it would look like.
... The diff and the changes to the actual text in the charter are available in link from survey and IRC

<Rachael> https://docs.google.com/document/d/1lrBIprp-80cePkkoGF8PNwMCwpypEhLQhon4tE89hio/edit#heading=h.whqbkrs6jekj

<u9000> thank you

Rachael: Additional links with more info in survey.
... We had a lot of agreement with moving the W3C policy in survey.
... Pulling topics of conversation out of that, and recognizing tha twe have pretty big support for it, want to talk about folks' feedback.

Ensuring big decision have enough time and attention

Rachael: First topic: some concern about making sure decisions get enough time and attention. Note that the charter-proposed text has a *longer* time to consider CfCs (5-10 day vs current 4+ day), but wanted to open floor for concerns.
... Seems everyone is comfortable knowing that the time will be longer.

Clarifying weakest objections

<Rachael> https://www.w3.org/2023/Process-20230612/#Consensus

Rachael: Next topic is around wording of W3C default policy around "weakest objection". Policy section 5.2.2 states "Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people."

<Rachael> Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

Rachael: We used to have somewhat similar wording in our custom policy, though we removed wording around "strong objection" because there was confusion about what that meant ("feel strongly" vs "strong on technical merits")

<LoriO> presetnt+

Alastair: I think this is fine so long as we have an understanding as a group that "strong objection" should be along the lines of "strong on technical merit"

Wilco: Curious what that means in terms of accessibility

Gregg: Suggest maybe adding a word ("strong technical objection"?) to clarify, but not sure what word should be
... "Strong argument"? Maybe not, sounds like asking for an argument. But we should think of a word to add to clarify the meaning.

<Zakim> alastairc, you wanted to talk about examples of strong/weak and to also mention we can't directly edit the W3C decision policy

Bruce: Wondering if chair might record a decision - do we have an example of recording a decision of dissent we can refer to?

Rachael: looking for that while we continue on

Alastair: On Wilco's question about strong/weak: Will mostly be drawn based on requirements we're working on. Would assume a strong objection would be something like "this doesn't actually improve accessibility" or "this think is infeasible to implement"
... Trying to include both sides of the continuum of "an organization implementing something" vs "benefit for a user" - think either of those could be basis of a strong objection

<Rachael> All our formal CFC decisions are recorded at https://www.w3.org/WAI/GL/wiki/Decisions

Alastair: Would go back to the requirements document in question as far as "what is this spec trying to achieve".
... On Gregg's concern: hard to add a word inline into the main W3C decision policy, but we could incorporate an update in our own charter if we wanted

<kirkwood> my thought: negative effect on accessibility for a particular disability group.

<GreggVan> +1 to not trying to add a word to W3 policy.. grin

Rachael: Pasted in IRC our CFC records, which do include some examples of objections and non-unanimous concensus.

<Zakim> Chuck, you wanted to offer my opinion on "strong technical objection"

Rachael: In WCAG 3, it currently works a bit differently at low maturity levels, those are recorded in the draft as editors notes

Chuck: Whatever the words are to explicitly describe it, I'd like to try to avoid limiting; but I want to clarify that strength of conviction is not enough on its own to merit a strong objection, there needs to be some sort of objective measure to it.

<Zakim> tzviya, you wanted to clarify some issues about consensus

Chuck: Don't want to limit ourselves, but do want to get beyond "passion and conviction" being enough on its own

Tzviya: Think we should maybe look into what other W3C groups are doing. My experience with many other groups and the process document aligns with Chuck - we don't need to imagine all the possibilities for how folks can object to things. Think the current process has worked for many groups for many years, can't see why it wouldn't work for WCAG.

<bruce_bailey> 19 April 2021 notes an objection. I think that is an example like I was asking for "recording dissent".

<bruce_bailey> https://www.w3.org/WAI/GL/wiki/Decisions#2021

Wilco: Curious to hear from chairs if they think this biases process towards a more technical approach on the standard. Does that mean that people making arguments from equity might pull a shorter straw here if there's a technical argument to not include something vs an equity argument to do so?

<laura> Good question from Wilco.

Lori: Not sure about wording Chuck mentioned. If someone has a very strong opinion and they're only 1 or 2 people with it - shouldn't we think about that still? We shouldn't discount small opinions just because they're only a few people.

Rachael: The intended design of the consensus process is specifically meant to give weight to a small number of people with a strong objection. We aren't intended to conflate "strong" with "large number of people". We're more discussing issues where someone might say "I strongly object" but not be able to articulate why, exactly.

<kirkwood> +1 to keeping wording general

Rachael: I personally prefer to keep the wording general, because our charter and decision policy are fixed for years at a time, and folks are tired of talking about how we're going to get work done and go get work done.
... We have a choice about whether to make everything very fixed in a hard-to-change document (there *are* benefits to that) vs have some small number of fixed finite parameters. We could put what we mean and don't mean about "strong objections" in our internal policy document without making it part of our charter's formal decision policy.

<Zakim> Chuck, you wanted to offer an opinion on "technical bias"

Rachael: Definitely agree with Wilco's concern about equity vs technical concerns, think that's a point in favor of keeping it vague in the formal decision policy

Chuck: When we hear someone say "I object strongly", I mostly want to say "Okay, why?" and not leave it at "I strongly object". Want to be sure we get at "why".

<Zakim> tzviya, you wanted to say we use the same process for the Code of Conduct

Chuck: For Wilco: Simple answer is "no", don't foresee any concerns about biasing towards "just technical" objections - just want to bias towards being able to get to "why"

Tzviya: We use this process for developing a code of conduct in other groups, which is completely non-technical - think if it works for that, it should work for anything

<Zakim> GreggVan, you wanted to ask "Wilco what do you mean a "technical argument against?"

<Rachael> Straw Poll: 1) Keep general wording and add clarifications as needed to a shared process document 2) Add clarification to the Charter 3) Keep the custom policy which documents this 4) other

Gregg: Final judgement of "is it a strong objection or not" falls to chairs, ultimately, and I am fine with leaving it general and tossing it to chairs to make judgement calls where necessary. Don't think we need to deep dive on this; trust that chairs will give objections fair treatment.

<shadi> 1

<Ben_Tillyer> 1

<tzviya> 1

1

<GreggVan> 1

<Chuck> 1

<alastairc> 1

<u9000> 1

<jeanne> 1

<ShawnT> 1

<bruce_bailey> 1

<katy> 1

<garcialo> 1

<Wilco> 3

<Rachael> 1

<kirkwood> 1

<mikeGower> 1

<LoriO> 3

<Chuck> 16 1's, 2 3's

<Raf> 1

<Chuck> 17 1's, 2 3's

Rachael: 1 was keeping W3C policy and keeping up a shared policy document, vs 3 being maintaining our own

Wilco: Prefer 3 because they seem kind of equivalent

Shadi: Wilco, if they seem similar anyway, why invest in maintaining duplication of what's there?

Wilco: Think the process doc we have today provides more clarifications than the W3C document has. It sounds like we'll need to write down the clarifications we want to keep anyway. But also, I don't feel particularly strongly about this, happy to go with the group's decision.

Ensuring big decision have enough time and attention

Flexibility vs. detailed step-by-step process

Rachael: Are we okay with a bit of flexibility in process vs having everything written down and codified?

<Chuck> + 1 to flexibility

Rachael: In some ways, it moves some process conversations out of the whole group and back to chairs, but it's not necessarily something that has to constantly come back to the whole group for discussion and adjustment

<Zakim> bruce_bailey, you wanted to ask about charter with regard to (1)

Rachael: That to me is the big difference.

Bruce: To clarify: the time-sensitive thing is having a charter, yes? Is the group comfortable just referencing the W3C policy and *not* referencing some custom process?

<Zakim> alastairc, you wanted to comment on where it affects how we do things

Rachael: Yes, that's the bigger question, but wanted to discuss the first question before going to the formal decision about charter timing

Alastair: On Wilco's point: I think having this flexibility will be useful. Working backwards from when a spec gets to a decision point for moving forward: those aspects will stay very similar to how they are now. think the flexibility will more be used in early stages of the process, where we're thinking about how we can maybe, for example, move CFCs for early work to a different medium (GitHub vs email)
... Maybe create a notification mechanism that everyone receives on a weekly basis and use a more asynchronous process or something.

<Rachael> q

Alastair: But we need to get a decision policy and charter sorted out fairly quickly.

Charter text

Rachael: Last theme that came up in the survey feedback was on the actual charter text.
... The proposed text mostly pulled from other groups, though we added a few tweaks.

<Rachael> To afford asynchronous decisions and organizational deliberation, any resolution for normative text (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from 5 to 10 working days, depending on the chair's evaluation of the group consensus

<Rachael> on the issue.

<alastairc> https://docs.google.com/document/d/1lrBIprp-80cePkkoGF8PNwMCwpypEhLQhon4tE89hio/edit#heading=h.l30gf7k0gn7x

Rachael: There were questions about what exactly this means. Are we doing a full email CFC for every decision we make?
... No, but decisions would go somehow for a CFC. That might be, for example, "review in GitHub and leave comments there"
... There are other ways we can do things that aren't necessarily our current email process that could move us forward in a faster fashion.
... But I think we can move to faster methods regardless of whether we use the W3C decision policy vs our own - as a chair, I think choosing to use the W3C version is no more or less restrictive for this specific concern.

<kirkwood> is there the potential of creating a less accessible process for some?

Wilco: Can you clarify - my understanding of current process is that for, eg, exploratory content, no CFC is necessary at all. This doesn't seem to be the case for the new process; it looks like it needs a CFC (somehow, with some process). Am I misreading?

Alastair: On the W3C doc/process, it's distinguishing between the editor's and working draft. Anything going to the working draft needs a CFC process, but stuff going into editor's draft doesn't.
... Similarly, informative content doesn't necessarily need official resolutions.
... Gives flexibility to early stage of process, but still need CFCs for moving stuff into working draft.
... For folks who are newer, for reassurance: There is a quite a large incentive on chairs to not store up problems for later. Moving to working draft is when official objections can be filed, but it's very much in the chairs' best interest to get issues resolved before going to that point, so hopefully that gives some reassurance.

<Wilco> +1

<Zakim> Chuck, you wanted to ask about scribe change

John: My only concern seems like it was a little bit covered in background earlier. It's the potential of the process being less accessible to some. For example, there might be some folks that find the tracking of GitHub issues almost impossible, and the current process of things bubbling up in meetings/email might be more accessible to folks. I worry that the effect might end up less accessible to some people.

<Wilco> scribe+

<Zakim> alastairc, you wanted to comment on accessibility of process (around github)

<Wilco> Alastair: That's something we have in mind

<Wilco> ... We're likely to focus more on GitHub, but I think we can use mechanisms to make that simpler

<Wilco> ... The diversity of places where things can happen is a common problem.

<Wilco> ... Github accessibility has improved. We're trying to keep surface area small

<kirkwood> very good

<Wilco> ... We can do some training and support on that as well for everyone

<Wilco> DJ: Mailing lists themselves can be inaccessible for many reasons

<alastairc> There are no universal solutions, and the more solutions we use the more spread out things are (and harder to follow)... arg!

<Wilco> ... GH issues can work like mailing lists

<Wilco> Rachael: We're looking at how we can create an accessible process for everyone. We'll run this by everyone

<Zakim> bruce_bailey, you wanted to ask i am still confused as to why charter need to reference AG Working Group Decision Policy

<Wilco> ... Even as chairs its difficult to track down issues. This is part of the next step

<Zakim> Rachael, you wanted to answer

<Wilco> Bruce: I'm confused then as to why are charter needs to reference the AG decision policy

<Wilco> Rachael: That's the question, do we reference the AG decision policy, which makes it difficult to change, or do we maintain a separate document

<alastairc> Previously we did reference a separate decusion policy, so the proposal is not to do that.

<Wilco> ... It seems we have consensus to maintain a separate document, but not have it in the charter

<ShawnT> Have we looked into using the Github APIs to have webpages pull information based on the labels, maybe even finding a way to link the mailing lists

<Wilco> Bruce: The google doc has proposed changes. So that will go into the charter.

<Rachael> https://docs.google.com/document/d/1lrBIprp-80cePkkoGF8PNwMCwpypEhLQhon4tE89hio/edit#heading=h.l30gf7k0gn7x

<Rachael> draft RESOLUTION: Agree with using the W3C decision policy

<alastairc> Shawn - I don't think so, but we need to better flesh out how we work through WCAG 3 issues and then how to export / import things.

<tzviya> +1

<dj> +1

<jeanne2> +1

<Chuck> +1

<kirkwood> +1

<mbgower> +1

<mgarrish> +1

<bruce_bailey> +1

<Wilco> 0

<katy> +1

+1

<ShawnT> +1

<alastairc> +1

<ChrisLoiselle> +1

<LoriO> +1

<Francis_Storr> +1

<Rachael> +1

<Wilco> Wilco: no additional points

<Chuck> 16 1's, 1 zero

<Ben_Tillyer> +1

<laura> 0

<Chuck> 17 one's, 2 zero's

WCAG 2.x backlog issues https://www.w3.org/2002/09/wbs/35422/wcag2x-backlog1/results

RESOLUTION: Agree with using the W3C decision policy

<Chuck> +1 for 45

<Wilco> Rachael: We'll go 30 minutes more for WCAG 2

<dj> thank you all

Is visited link color a failure of Use of Color? #905

<Wilco> Alastair: Issue on use of color, where a question that comes up often is if visited and unvisited link is conveying information. Whether that would fail use of color

<Wilco> ... Browsers restrict what you can do. A suggestion was to add a section that says visited is not part of use of color

<Wilco> ... Bruce had an editorial suggestion.

<bruce_bailey> i did not insert suggestion (i do not think)

<Wilco> ... I wasn't sure what Stefan was referencing.

<Wilco> ... GN wasn't sure whether its beneficial to distinguish visited from unvisited.

<Wilco> ... Wilco agreed, wasn't sure from the comment.

<Wilco> Rachael: I believe what GN is saying whether visited / unvisited is information that needs to be conveyed.

<GN015> +1 that's my point

<Wilco> ... We need to make sure we're agreeing that visited / non-visited is important that it'd need to be conveyed

<Wilco> Alastair: If authors take away the visited state it wouldn't fail

<Chuck> scribe+ Chuck

<Chuck> wilco: It's sort of the same thing. State is information.

<Zakim> Rachael, you wanted to speak to GN's point

<Chuck> Wilco: There's 2 SC that state this, and have requirements for state. Not text contrast and name, roll, value

<Chuck> Wilco: If we say it's a state (and I don't think we should), then we need to...

<Chuck> Wilco: Using that word "state" is triggering. I don't think we want to get close to that.

<Zakim> bruce_bailey, you wanted to say visited / unvisited *is* information -- but i think response is fine regardless

<Chuck> alastair: If we don't call it a state, then we are ok.

<Wilco> Bruce: I think visited/unvisited is information, but I don't think it effects accepting this PR

We literally call out "visited/unvisited" as an example in the normative definition of "state"

<Wilco> ... We don't have to answer whether this is information or not for this PR

<Wilco> Lori: Why would we not want to use state? A link only has two things, visited or non-visited.

<Wilco> Alastair: If we call it a state it overlaps with other criteria about state

<Wilco> ... There are many more states than visited/unvisited. We have active, hover, ...

<Wilco> Lori: Focus is not a state

<Wilco> Alastair: Its at least as much a state as visited/unvisited

Again, we explicitly call out "focus" as a state in the normative definition of "state"

<Wilco> ... All of these things can overlap and interact. When it comes down to styling things it makes it very difficult.

<Zakim> mbgower, you wanted to say if it isn't a state, what is it?

<Wilco> Mike: Not calling it state doesn't get us away from conflict with existing SCs. 4.1.2 is about states, properties, and values.

<Wilco> ... What we're running into is there is a limitation to what the author can do

<bruce_bailey> +1 to mike that, if not a state, visited/unvisited is a property

<Wilco> ... They can't meet 4.1.2 for visited/unvisited. It's impossible

<Wilco> ... The author cannot meet that criteria

<laura> +1 to Mike

<Wilco> Dan: To clarify, we have a normative definition of state, it explicitly includes focus and visited/unvisited

<Wilco> ... I agree it's not super relevant to use of color specifically.

<Wilco> ... My understanding is we want to avoid creating an impossible requirement, but not to imply authors shouldn't meet other contrast requirements

<GN015> Dan, that clarifies my question

<Wilco> ... Distinguishing that a link is a link, regardless of visited.

<Wilco> Ben: When I'm auditing I've seen a lot of examples where auditors called out the lack of contrast between visited/unvisited.

<bruce_bailey> @dan could we have URL to "visited/unvisited" in list of examples ?

<Wilco> ... They've made use of CSS pseudo-class, which appears in modern browsers. There are ways to do this.

<Wilco> ... At least one of the big UK consultancies reports this often.

<Wilco> ... The second point I want to raise, is this conversation just on inline links that use an anchor tag, or does it apply to role=link element?

<Zakim> alastairc, you wanted to comment on visited link and authoring

<Wilco> Alastair: Browser massively restrict how you can style visited links for privacy reasons.

<Wilco> ... The only things you can change are colors. Authors only have colors to distinguish visited/unvisited links.

<Wilco> ... You also wouldn't fail the if there are no differences.

<bruce_bailey> Link from survey on privacy and visited/unvisted : https://developer.mozilla.org/en-US/docs/Web/CSS/:visited#privacy_restrictions

<Wilco> Alastair: This last sentence can be tweaked.

<alastairc> "or these reasons, setting or conveying a link's visited status (in comparison to non-visted) is not an author responsibility"

<bruce_bailey> link for definition please ?

<Chuck> Wilco: I was not aware that hover was not in the definition of state. Visited/Unvisited is. We need to call it a state.

<Wilco> Dan: What resonated the most with me is what GN brought up. The browser offers an alternative.

<Wilco> ... You could argue that being able to distinguish visited/unvisited is not necessary because there is a path to get that information; the browser's history functionality.

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

<Wilco> Mike: I don't think it's relevant to the SC normative text

<bruce_bailey> States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collaps

<Wilco> Alastair: It's information available from the browser

<Zakim> mbgower, you wanted to say there is no exception for 'other means'

<Wilco> Ben: If you're going to say that the history function can be used to know if it's visited or not, then we might as well say use devtools to get the other information.

<Wilco> Mike: I believe this is only concerned with color. We can include user agent history in the understanding document, but I don't think it solves that we need an exception, because the authors can't do anything about it.

<Wilco> Alastair: So with that adjustment in might, lets see if we can get agreement on that and have further issues separately

<Rachael> draft RESOLUTION: Accept PR 3222 with adjustment to clarify the difference between visiting and unvisited links and file more issues if needed

<Ben_Tillyer> +1 to bruce

<Wilco> Bruce: Did my editorial get into the PR? And separately, do we want to mention this is easy for the authoring tools to fix

<Rachael> draft RESOLUTION: Accept PR 3222 with Bruce's editorial change, adjustment to clarify the difference between visiting and unvisited links, note that user agents can help with this, and file more issues if needed

<GN015> did you mean to write visited instead of visiting?

<Rachael> draft RESOLUTION: Accept PR 3222 with Bruce's editorial change, adjustment to clarify the difference between visited and unvisited links and file more issues if needed

<mbgower> +1

<ShawnT> +1

<alastairc> +1

<bruce_bailey> +1

<laura> +1

<Ryladog> +1

<Wilco> +1

<Ben_Tillyer> +1

<Francis_Storr> +1

<ChrisLoiselle> +1

<Chuck> +1

+1

<kirkwood> +1

<Chuck> 13 one's

<LoriO> +1

<GN015> +1

<Chuck> 15 one's

RESOLUTION: Accept PR 3222 with Bruce's editorial change, adjustment to clarify the difference between visited and unvisited links and file more issues if needed

Add definition for “path-based gesture” for 2.2 #758

<Wilco> Mike: There are a lot of people involved with different considerations. I just wanted to say thanks.

<Wilco> Alastair: This is a normative change, it effects WCAG 2.1. It was raised by Jake because it seemed something should be defined

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag2x-backlog1/results#xq26

<Wilco> ... We had support for the definition, but because it's an errata for 2.1 that would go into 2.2 as well it would need good support, and no objections.

<Wilco> ... We had support, but we also have some objections. If the understanding document can clarify this sufficiently it seemed like a reasonable mitigation.

<Wilco> ... Several quite strongly against adding it as a normative definition.

<Wilco> ... Otherwise, at this stage it means we'd not add the definition.

<Rachael> draft RESOLUTION: Use the understanding document to clarify path-based gestures

<Wilco> Bruce: If we're not willing to do so, I think it's the correct thing to do.

<Ryladog> +1 to Bruce

<Wilco> ... It's important the concept ripple back to 2.1 and 2.0

<Wilco> Bruce: You do need it in 2.0, it has the same concept in SC 2.1.1

<Rachael> Straw Poll: 1) Object to only using the understanding document 2) Object to adding a definition 3) Can accept either way

<Wilco> Mike: I believe this is a normative change. I don't see the necessity to do it right this minute. We can easily add more to the understanding document.

<Wilco> ... If it's going in as an errata, we'd want to take time to do it properly

<Zakim> alastairc, you wanted to comment on timing

<Wilco> Alastair: This is the WCAG 2.x backlog. We've started almost at the bottom on issues that have had resolutions.

<Wilco> ... WCAG 2.2 is in CR, it's about to finish. I think this would be an errata.

<Chuck> wilco: I think this is a substantive change, and that needs another CR, can't go in just an errata.

<Chuck> wilco: I don't think w3c process allows a substantive change w/o CR.

<Wilco> Michael: I think we're allowed substantive changes in an errata. They're not normative until they are in the recommendation.

<Rachael> Straw Poll: 1) Object to only using the understanding document 2) Object to adding a definition 3) Can accept either way

<mbgower> we did this for the red flash threshold, I believe

<Wilco> ... Getting them in the recommendation would mean go through the process

<Chuck> 3

<Ben_Tillyer> 3

<LoriO> 3

<ShawnT> 3

<alastairc> 3

<Rachael> 3

<Wilco> 2

<bruce_bailey> 3

<Raf> 3

<Ryladog> 3

<laura> 3

<mbgower> 2 without quite a bit more scrutiny

<Chuck> 10 three's, 2 two's

<GN015> 3

<Chuck> not opposed to more scrutiny

<Wilco> Rachael: What I've heard, at this time the group isn't comfortable, but we might want to revisit

<Chuck> 11 three's, 2 two's

<Wilco> Alastair: I think that's fine. The PR did include the suggested definition from the understanding documents.

<Rachael> draft RESOLUTION: Do not merge PR 3234 at this time but consider revisiting as part of WCAG 2 task force

<Zakim> bruce_bailey, you wanted to ask about adding definition in Understanding?

<Wilco> Bruce; There are other places where we have definitions that are only in understanding

<bruce_bailey> i change my vote to (2)

<Wilco> Alastair: Usually it doesn't raise to the level of a formal definition is when it's used in multiple criteria

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/insert suggest (i do not think)/insert suggestion (i do not think)/
Succeeded: s/thinks/thanks/
Succeeded: s/my yot/my vote/
Default Present: ShawnT, alastairc, shadi, Rachael, dan_bjorge, tzviya, ChrisLoiselle, Ben_Tillyer, garcialo, Cyborg_, Francis_Storr, mbgower, bruce_bailey, katy, Laura_Carlson, Raf, mgarrish, GreggVan, Chuck, kirkwood, u, Katie_Haritos-Shea
Present: ShawnT, alastairc, shadi, Rachael, dan_bjorge, tzviya, ChrisLoiselle, Ben_Tillyer, garcialo, Cyborg_, Francis_Storr, mbgower, bruce_bailey, katy, Laura_Carlson, Raf, mgarrish, GreggVan, Chuck, kirkwood, u, Katie_Haritos-Shea, u9000
Found Scribe: dan_bjorge
Inferring ScribeNick: dan_bjorge

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)