<Chris_Loiselle> I'm at Chris_Loiselle , kick off ChrisLoiselle

<scribe> scribe: hdv

Intros

alastairc: is there anyone new or are there changed affiliations?

Chris_Loiselle: I'm no longer at Oracle, I am an Invited Expert

alastairc: glad to have you carry on

<Chris_Loiselle> Thanks all!

<Ben_Tillyer> "Welcome back" Chris :P

Announcements

Chuck: the CFC for WCAG2ICT is going to close later on today
... some changes to the note were changed, in our opinion not controversial or substantive, but we'd like everyone to know and if you have concerns, please review and let us know by COB today
... we intend to close the CFC as we normally would

<Daniel> WCAG2ICT Review issue

<Daniel> Most changes were editorial, and have now been merged into the Editor's Draft and the staging branch. Consistency in the use of some phrases, update editors and contributors information, etc.

<Daniel> Remove problematic note that didn't align with the understanding doc as per Jonathan Avila's comment

Daniel: I'll go through the changes

<bbailey> HT to Jon for catching the typo !

Daniel: most of them were editorial and inconsistent wording, like 'meet' instead of 'satisfy'
... and requirements for contrast vs contrast requirements
... these were before the CFC started
... the change we made after the CFC started, is in PR 768, which is a removal of a note, that according to Jon Avila and others in TF, was not very aligned.
... we just didn't merge it into the doc you're currently reviewing

<Chris_Loiselle> agreed to what Daniel stated.

Chuck: we are planning to close the CFC but if you have concerns please let us know today

Preparing for publication

alastairc: our only agenda item today is prep for publication.

<alastairc> https://github.com/w3c/wcag3/pull/350

alastairc: this is the link to the PR, it has a link to the preview Rachael is sharing at the moment

<Rachael> link to preview: https://deploy-preview-350--wcag3.netlify.app/guidelines/#no-misinformation

alastairc: everything here is what we're proposing to put forward for our next Working Draft, assuming it is marked as 'Developing'
... it takes out all of the exploratory items

<kenneth> "without early-stage" filters out exploratory, placeholder, or "needs additional research"

Rachael: we're currently looking at the preview that still has the 'exploratory' and 'needs further research' items

kevin: it is possible to remove the items that are going to be removed with the 'preview without early-stage entries' link Ken made

<julierawe> Rachael Will the published draft include an impossible-to-miss note saying that all of the exploratory requirements are hidden in this published draft?

alastairc: we're still doing some editorial work, and will be over next few weeks; but in general this is the place we'd like people to review

<alastairc> https://docs.google.com/document/d/1V7XalBenBlMsu3_C965UzpmJ82RUilD2DCHz0MvRn24/edit?tab=t.0

alastairc: if a subgroup hasn't worked on something, we'll leave it as exploratory, but won't be in the public preview version
... if the subgroup did work on it, so it is 'developing', we ask a number of questions (as shared in the doc)
... first question is, is it covered by other regulation, like privacy?
... second is, does failing it have a disproportionate deterimental effect on people with disabilities?

Rachael: this was a very difficult question to formulate and we'll likely be refining over time

alastairc: we also check if the requirement has some kind of objective test to support it

GreggVan: is it correct 'exploratory' content is not going to be included in this release?

alastairc: correct

julierawe: could you go over the logic of sharing content without the exploratory content?

alastairc: they'll still be part of the editor's draft, which is public… but the public working draft we send out for review wouldn't include it, because last time we sent it out, we got a lot of feedback and we want to narrow it down to specifically the content that we have been working on

bbailey: was the introduction updated to reflect this triage?

alastairc: good question, I think it has been

GreggVan: it would be helpful to add one more sentence, 'if you'd like to see everything we are exploring, you can consult the editor's draft' and include a link

<Ben_Tillyer> +1 to Gregg

<Chuck> +1

<bbailey> +1 for link to editors working draft

GreggVan: on the same paragraph, probably also want to add if there's a topic you're interested in and you have content on that, please contact us. A call for action if people are concerned content is missing

alastairc: we do have some notes like that, but would make sense to add to the top
... we have some things we'd like to remove… one is the bit about 'pointer visible', we suggest to leave that as exploratory

GreggVan: using the user agent's rather than default is, so that users can change it in the browser so it works better for them

<alastairc> https://docs.google.com/document/d/1Aq8TYJEqwuvr2EeOJRan8vH1MT8P0B3n6v4HA6OM2o4/edit?tab=t.0#heading=h.8x9c1fmflbnw

alastairc: in the visual appearance subgroup it was separated out into various places. We're not losing this item, there';s more to be added, it's just not ready yet

Rachael: the next one is 'information privacy'. there's a series of requirements this falls into. The challenge we're finding is that they overlap with other regulations, specifically ones about privacy and security
... *reads out the specific requirements in information privacy part of the table
... question: if we leave these out, do we want to add them to the policy document?

GreggVan: I agree. Lots of things that have to do with information that don't belong in this document
... one thing that does belong is adaptations added to increase the a11y of the document do not decrease privacy or security
... like a kiosk that doesn't provide a headphone jack so it plays all personal information out loud
... another one is, to make it accessible you remove the dots on the screen and make the password visible
... in other words, when you make things accessible, do it in a way that does not decrease privacy or security

LoriO: want to add one more: when data is collected on AT usage or disability related vulterabilities

<Jennie_Delisi> * that is someone else, not me

<Zakim> Jennie_Delisi, you wanted to discuss COGA related requirements for understanding

Jennie_Delisi: while I agree that pulling these reqs out, I want to make sure we don't lose some of the COGA needs

Rachael: we originally had requirements around privacy and security, but the more we looked at it, if it is part of digital content, it must meet the other requirements of WCAG 3, we were being redundant of other requirements. Maybe it is useful to pull out specifics

alastairc: so far I'm not hearing anyone saying we should keep these specific items in the draft
... any objection to removing these?
... [silence] will add 'agree to remove' to doc for now

Rachael: re global privacy settings, an editor noted it is not clear that this is an accessibility specific provision

+1 to Kevin's point

Rachael: the next one, accessibility privacy settings, where the amount can be adjusted, it relates to the cognitive burden.
... we commented that adding this req would be redundant

GreggVan: I'm worried that taking all information about users is taken unless people can figure out how to turn that off

Jennie_Delisi: when a group looks at what barrier is presented, when it comes to cognitive… I'm not sure in the future if we have the ability to show the impact in a way that's scoreable

Azlan: I think disability information should be treated like any kind of personal information. Did want to ensure that situations like the kiosk example, that private information was not being publically announced
... also how much can be inferred from how much is recorded by the assistive technologies and whether you can state what kinds of impairments are being experienced by the user, I don't know

julierawe: will there be something left that covers privacy? will we get to that intersection of accessibility and privacy?

Rachael: this is more about overlap with privacy law than with other criteria or requirements
... I think Julie and Jennie's questions are somewhat similar, how can we address the concerns around accessibility and privacy going forward?
... I could see us do that in various ways, including in the policy guidance document
... if there are certain things in privacy settings there are sub categories that need specific considerations.

<Zakim> alastairc, you wanted to comment on keeping the 'redundant' ones to compared with other provisions later.

alastairc: maybe we can compare redundant ones against other provisions in a document
... some apply to lots of different interfaces

<Jennie_Delisi> Testable and scorable impact?

alastairc: when a group looks at the size of the barrier, not sure how that could be dealt with, is probably not specific to privacy like concerns
... EN 301 549 has an extra provision around providing information re if you have a disability

<Zakim> GreggVan, you wanted to say "Where charaters are masked visually on screen - any auditory output is also masked by reading what is displayed "dot dot dot" rather than what is

todd: I'd rather us not lose the the direction we're going

GreggVan: regarding all these privacy items, I think removing them is not a great way forward, we should remove them and then put them in some kind of purgatory, we just keep them in some place. I'm particularly worried about cognitive
... the privacy laws maybe don't take into consideration that some people don't know how to turn things off
... agree we need to set them aside for now but rather than keeping them entirely off we needto have them in a place where we can refer back to later

<Chuck> +1

Rachael: based on this conversation I hear we're not ready to leave these requirements just yet, I would recommend that we leave them at Exploratory

<GreggVan> +1

julierawe: also in favour of keeping them. If some are not testable we can change them to assertions

<Zakim> alastairc, you wanted to ask, if a privacy law covered these things in general, and pointed to WCAG3 to say "also make it accessible", would that work?

<GreggVan> +1 to julieawe

julierawe: continuing to look for the intersection and where can we encourage developers to make these in a way that don't exclude users that'd be great

alastairc: <chair-hat off>if you imagine you're in an area with privacy laws, like GDPR in EU… they pointed to privacy docs and also to WCAG 3 … what would they miss?

Jennie_Delisi: there are certain exceptions written into regulations that enable the bypassing of certain requirements, and I've seen that in key places. There are logical reasons at times, but it is something this group has to acknowledge
... we have to make sure the criticality of certain information is included

<Zakim> GreggVan, you wanted to answer Alastairc and to say -- good idea alastair -- Good to also include (in those regs) "and that information about disabilities is important to

Jennie_Delisi: the COGA group has thought a lot about this, would be good to chat with them about this too (not speaking on behalf of COGA)

GreggVan: it's a good idea to recommend treating informaton about disabilities as a more sensitive category

todd: to Jennie's point, I'd love us to have this conversation with COGA

<Chuck> qq+ to ask for scribe change

<julierawe> I can facilitate!

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

<Jennie_Delisi> * thank you for the discussion - really appreciate that this could be discussed by this group. And, for the efforts of the subgroup. Important topic.

<kenneth> scribe+ kenneth

<kenneth> Rachael: I want to confirm that we have general agreement around the privacy settings, because I want to skip them as a group if this is true. Does anyone object to moving them to exploratory and then working as a group to address these comments?

<kenneth> Kevin: Given that I was probably the editor most strongly against including these, I would like to be involved in those discussions

<julierawe> Will do :)

<kenneth> Rachael: First of all, I want to thank the media subgroup that worked on this, a huge amount of work was done

<kenneth> ... as editors we noticed a lot of overlap between the 3 sections; we've deduped and reorganized, so they look quite different now. I will be sending a detailed note to the group after this meeting.

<kenneth> ... first: Captions are synchronized. Suggesting removal because it is redundant. Captions are defined as synchronized within the immediate definition

<kenneth> ... If we want to keep this, I suggest we keep it more detailed around timing, in which case maybe move it back to exploratory for more work.

<GN015> I recommend or at least would like to allow to show captions before the audio can be heard, as this way the user has time to visually focus the text.

<kenneth> GreggVan: We and I spent an enormous amount of time on this in EN 301 549. A couple of comments to help frame this:

<kenneth> ... first of all, we make no requirement as to timing on the author's point, but we do say that it needs to be displayed within 100ms of the time that it is marked on the timestamp to be shown

<kenneth> ... there is a recommendation that targeting even faster down to 20ms is good, but that is down more to players than authorship

<kenneth> ... Authors will say that users say that they prefer captions to show up slightly before, not so that it spoils things, but so that they can read it in time for things to show up

<kenneth> ... if there's a lot of dialogue, rather than having it fall further behind, sometimes you will push the first caption forward, and the second one has to be later, because otherwise the first won't be on-screen long enough to be fully readable

<kenneth> ... if the dialogue stops but was very long, may make sense to have the caption remain on screen longer to allow viewers to finish reading

<kenneth> ... so there can be more to this than absolute sync / showing up exactly on time with the dialogue happening.

<GN015> +1 to Gregg

<kenneth> Ben_Tillyer: While I agree with Gregg RE what showed up in EN 301 549 RE browser/agent responsibility, I understand the concerns of it being a really difficult topic. We haven't even touched on live vs. recorded, whether it's being transcribed live, whether there's an AI agent, etc.

<kenneth> ... but I don't think it should be dismissed. I think we need something, but I don't have it off the top of my head right now.

<kenneth> ... could be some percentage of words represented in captions, etc.

<kenneth> ... I think there's more work to be done here.

<kenneth> Rachael: Does anyone object to moving it back to exploratory for this round?

<kenneth> alastairc: It does sound like it kind of needs to be redone, because in the current form it's not adding anything.

<kenneth> GreggVan: We should also have experts in doing captions involved.

<kenneth> ... The problem people conflate is sometimes they see captions that are as much as 5-10 seconds late, and that's a problem. The solution isn't to say things have to be exactly synchronized, it means they can't be wildly out of sync, which then needs to be defined.

<kenneth> Rachael: The next set is all around language. Some of these require captions to be available in multiple languages; some require the content author know who the target audience is and ensure captions are provided in that language.

<kenneth> ... When we talk about captions in other languages that seems like potentially a subtitling thing which is not directly related to accessibility.

<kenneth> ... While speaking a foreign language can overlap disabilities, which is brought up in COGA, it is not itself a disability

<kenneth> GreggVan: Again mirroring EN 301 549: we use the word "captions" only when quoting WCAG. Other places we talk about subtitles.

<GN015> I learned by definition cations are in the same language as the dialogue and meant for people who are deaf or hard of hearing (and also include the description of sound), while subtitles address users of other languages.

<kenneth> ... A weird situation can come up with interlingual subtitles when suddenly the caption would be in the same language and the audio, where there is no requirement

<Zakim> alastairc, you wanted to check i18n of terms, and whether there is a same-language thing to include? I.e. matching the spoken language.

<GN015> What about "if subtitles are provided in a specific language, also add captions (which then include the description of crucial sounds, who talks and such) in that language"? This way deaf users are not disadvantaged compared to hearing users of a language where subtitles do exist.

<kenneth> alastairc: Chair hat off: I do think anything which says "in the target user's language" will be problematic for an open thing, because I guess you'd have to let the person making the conformance claim define their target users, which is very gameable

<kenneth> ... from UK perspective, I had thought captions were referring to inclusion of sound effects and other things, whereas subtitles were whether you could understand the spoken language

<kenneth> ... is there a "same language" aspect? e.g. if the spoken language is English, then captions are required in that language?

<kenneth> ... you can provide more, but as a minimum you would include captions for languages that are part of the spoken content.

<kenneth> ... unsure whether the group has covered that elsewhere.

<kenneth> Frankie: We do cover that in the technique list; it is about matching, and we have several examples. I was expecting feedback on this.

<GreggVan> the latest EN 301 549 can be found at https://labs.etsi.org/rep/HF/en301549/-/issues/219 Use the CLEAN version for better understanding

<kenneth> Rachael: If I understood what you just said correctly, we are talking about potentially removing "Preferred language" and "Alternative language ..." requirements

<kenneth> Frankie: Makoto is not on the call; he had more points around keeping this stuff. I don't want to speak for him.

<kenneth> GN015: I'd like to suggest that many recordings or movies are available in different spoken languages; I think then it's clear that captions should be available in those languages.

<kenneth> ... If there are subtitles for users who can't understand the spoken language, there are also other audio cues, sound effects, etc.

<kenneth> Rachael: That should already be covered by other requirements

<kenneth> Ben_Tillyer: If I am watching a movie in French and I speak both French and English, but I have a hearing impairment, does that mean you are only letting me pick French language?

<kenneth> ... I might be able to understand French, but might find it easier to understand with English captions, not because I need a translation, but I find the audio difficult to parse without captions on screen, even if they are in a different language.

<kenneth> (Further clarification; concern seems to be covered)

<kenneth> alastairc: Wording we are looking at involves what is it we can require as a sort of minimum

<LoriO> +1

<Chuck> +1

<kenneth> Rachael: Reword the target user to what I just read; we will email the subgroup, and if there is pushback, we will move the requirements with pushback to exploratory

<kenneth> Rachael: We had some across the board that I've removed; e.g. captions in VR, we removed during rework but may keep it as an example (e.g. a method under Captions)

<kenneth> LoriO: As something affecting many users, disability or not, why wouldn't this still be a requirement, as an area that needs captions?

<kenneth> Rachael: We are already requiring captions in situations involving audio media, so this becomes one specific case/environment

<kenneth> LoriO: OK, I see

<kenneth> Rachael: Similarly, there were a couple of pieces around requiring human captioners. This is more of a method than an assertion or guideline; it's also partly future-proofing

<kenneth> Rachael: "Perfect set of alternatives" I think I've moved to an assertion under media alternatives, but it could be moved to a method; there could be strong arguments either way

<kenneth> GreggVan: Human captioners are not always better than AI, and this will change very fast

<kenneth> alastairc: So we are not removing these as methods, but we are removing them as requirements

<kenneth> ... and there will be a conversation with the subgroup as well

<kenneth> ... (Summarizing) We've agreed to move pointer visible and most of information privacy to exploratory, and some of media alternatives.

<alastairc> Proposed resolution: Agree to the outcomes in the document, regarding which requirements are going to be moved or removed.

<alastairc> https://docs.google.com/document/d/1V7XalBenBlMsu3_C965UzpmJ82RUilD2DCHz0MvRn24/edit?tab=t.0

<kenneth> GN015: So human describers and perfect set of alternatives (the last 2 in the list) also get moved to methods?

<kenneth> Rachael: Yes, currently; I could see a stong argument for making Perfect set of alternatives an assertion.

<kenneth> Frankie: In previous discussions, we had a lot of confusion around assertions. I'm not 100% we've resolved that confusion, which has resulted in moving a lot of things in and out between methods and assertions. So it would still be good to have clearer guidance to authors around which would be which.

<Chuck> +1 for providing refinement and clarity on definitions of assertions, methods, etc.

<alastairc> Proposed resolution: Agree to the outcomes in the document, regarding which requirements are going to be moved or removed.

<Chuck> +1

<ShawnT> +1

<Frankie> +1

<Rachael> +1

<kenneth> Rachael: now that we've gone through a bunch of these, we should have more information to improve guidance

<Azlan> +1

<GreggVan> +1

<Detlev> +1

<Laura_Carlson> +1

<bbailey> +1

<giacomo-petri> +1

<Gez> +1

<GN015> +1

<kevin> +1

RESOLUTION: Agree to the outcomes in the document, regarding which requirements are going to be moved or removed.

<Rachael> survey link: https://www.w3.org/wbs/35422/aug-pub-feedback/

<kenneth> alastairc: So those are all of the ones you won't find in this document. We would like you to review the rest of the document. This survey explains what to look for and consider while reviewing.

<kenneth> ... We have a couple of open questions at the bottom of the survey, though if you're comfortable with GitHub you can also comment on specifics there.

<alastairc> https://deploy-preview-350--wcag3.netlify.app/guidelines/

<kenneth> GreggVan: When I click on the PR link, I'm taken to a page where I have no idea what I'm supposed to review; I'm afraid that people who don't know GitHub will never find their way.

<kenneth> alastairc: First and foremost is the Preview link (first link in the PR description) will bring you to the preview of the document at the current state of the PR.

<kenneth> ... further, you may want to go to the top right of that document preview, and click "Preview without early-stage entries", to make it easier to focus on the entries in developing status.

<kenneth> Rachael: We will still be making small changes e.g. for typos. If we have more substantive changes to make, we will contact subgroups. Goal is to have something as clean as possible to send for CfC.

<kenneth> ... we will also be sending a second email, related to getting us further in conformance. Don't confuse that with this first survey.

<kenneth> julierawe: RE preview link: there are a few guidelines where all of the requirements are still marked as exploratory. Are these sections that subgroups haven't gotten to yet?

<kenneth> Rachael: Help and feedback is on my to-do list for this afternoon

<kenneth> ... User control, we'll have to check into.

<kenneth> ... I would recommend starting the review tomorrow, as we'll still be finishing up some odds and ends today.

<kenneth> alastairc: I would recommend starting at the top, where things are in Developing

<kenneth> GreggVan: So if things are in Developing, that means they have tests, correct? How do we find the tests?

<kenneth> alastairc: Would the pathways document be the best place to start?

<alastairc> Pathways sheet: https://docs.google.com/spreadsheets/d/1Ecg9qFIUVCUQfAPgNSEZ8MmsCSjbAynK8hbGBU8NrzQ/edit?gid=2035961492#gid=2035961492

<kenneth> GreggVan: The guidelines are not labeled as guidelines, so it looks like you have a requirement and then underneath it you have more requirements. When you get to 2.11 which has no requirements, the guidelines end up looking like requirements.

<kenneth> Rachael: We can take an action to label clearly

<Chuck> kenneth: That's a build system fix

<Rachael> If you want to dig into the tests link through to the pathways document at https://docs.google.com/spreadsheets/d/1Ecg9qFIUVCUQfAPgNSEZ8MmsCSjbAynK8hbGBU8NrzQ/edit?gid=2035961492#gid=2035961492

<Rachael> If you are not able to find a test, please reach out to chairs

<kenneth> GreggVan: In section 2.11, where there are no requirements, you should probably insert a parenthetical e.g. "(No non-experimental requirements yet)" to make it clear

<kenneth> alastairc: If people want to take a look now, we'll officially end the meeting. If you have any questions, we can be around to answer those.

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/this/alastairc: this/
Succeeded: s/preview buttons/'preview without early-stage entries' link/
Succeeded: s/Jennie_Delisi:/LoriO:/
Succeeded: s/drafft/draft/
Default Present: Laura_Carlson, Rachael, Chuck, tiffanyburtin, kevin, Adam_Page, shadi, Jennie_Delisi, shawn, hdv, Azlan, giacomo-petri, maryjom, GreggVan, Kimberly, AlinaV, joryc, mbgower, LTSzivos, CarrieH, Makoto, Detlev, Jaunita_Flessas, Jen_G, Rain, kenneth, Roland, LenB, sarahhorton, Frankie, SteveF, Francis_Storr, elguerrero, Ben_Tillyer, ChrisLoiselle, LoriO, filippo-zorzi, Charu, julierawe, Gez, graham, jtoles, Chris_Loiselle, alastairc, todd, Daniel, bbailey, MJ, ShawnT, again, GN
Present: Laura_Carlson, Rachael, Chuck, tiffanyburtin, kevin, Adam_Page, shadi, Jennie_Delisi, shawn, hdv, Azlan, giacomo-petri, maryjom, GreggVan, Kimberly, AlinaV, joryc, mbgower, LTSzivos, CarrieH, Makoto, Detlev, Jaunita_Flessas, Jen_G, Rain, kenneth, Roland, LenB, sarahhorton, Frankie, SteveF, Francis_Storr, elguerrero, Ben_Tillyer, ChrisLoiselle, LoriO, filippo-zorzi, Charu, julierawe, Gez, graham, jtoles, Chris_Loiselle, alastairc, todd, Daniel, bbailey, MJ, ShawnT, again, GN, GN015
Regrets: Jennifer Strickland, Roberto Scano
Found Scribe: hdv
Inferring ScribeNick: hdv

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: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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.)