AGWG Teleconference -- 09 Aug 2022

<Jennie> scribe: Jennie

<janina> present

Rachael: I am closing the survey

New members and topics

Rachael: Are there any new members on the call?

Bern: Hello. I am a new member

Rachael: Anyone else that is new?
... Any topics that we need to get onto our topic list for future conversations?

Announcements

Janina: APA has a horizontal review responsibility covering WAI specs and others

<janina> https://lists.w3.org/Archives/Public/public-apa/2022Aug/0005.html

Janina: We ended up getting stuck on the review in terms of one word
... Refers to the CFC
... The 2nd link points to the email
... This is a github issue 2305
... Sometimes acknowledging that more and more 3rd party content gets in

<bruce_bailey_> https://github.com/w3c/wcag/issues/2305

Janina: I would like to invite anyone who wants to weigh in to do so
... You can respond to the email, or participate in our conversation in 23 hours
... 10am Boston Time, to join the call
... Let me know if you need the Zoom information

<Rachael> TPAC: https://www.w3.org/2022/09/TPAC/

Rachael: TPAC is coming
... Early bird registration is closed, but you can still register
... Any other announcements?

Gregg: Question for Janina
... APA is suggesting an edit to our 2.2 document
... This would have to go in with a fairly major change I would think
... We would need a new call for conformance, correct?

Janina: I think Michael considered it editorial

<AWK> +AWK

Janina: Changing to "increasingly"

Rachael: We will note and talk about this at the chairs call
... But if you are interested in the topic, please reach out by responding to the email or going to the meeting

<Zakim> AWK, you wanted to ask about TPAC

AWK: I have a question about the TPAC schedule
... Monday, Tuesday, Thursday, Friday - correct?

Rachael: That is correct. We think it will be 1.5 hour blocks
... Then doing an in-person towards the end of the day
... We will try to get the agenda in full by next week

Gregg: Is there any reason why all the sessions aren't virtual?

Rachael: We figured 6 hours per day for 4 days is pretty exhausting

AWK: I have some conflicts on Monday and Friday - are we just working on WCAG 3 for the entire week?
... Are we resolving 2.2 comments?

Rachael: The goals is WCAG 3 the whole week

AWK: OK

Rachael: We will do our best to get the topics next week too

WCAG 3: Access to WCAG 3 Google docs https://github.com/w3c/silver/wiki#subgroups

<Jem> will be great to see the schedule ahead of time.

Jeanne: In working in the subgroups, there are a lot of people using Google Docs for early drafts
... for people in that group
... What we haven't done is present a unified process for "this is how you use the Google docs"
... It is important that these be preserved for future archiving purposes
... I worked on a list of the things you should do and not do when creating Google docs
... Where to store them, the subfolders that belong to the W3C
... We want to have the work archived in a place that belongs to the W3C
... What I would like to ask is that anyone participating in a subgroup to send me their preferred email address to give permissions to the folder
... This is for access to the Google docs, to edit them

<jeanne> [email protected]

<Rachael> Jennie: For those of us who have historical Google docs stored in our personal drives from 2.2, is there a place to transfer those documents?

Jeanne: That's a good question. Michael?

<Rachael> Jeanne: Great question. Michael?

Michael: I still have to learn how to do it, but it is on my to-do list

Rachael: More on this to come

Bruce: Is there an easy way to tell in Google Docs if I am in a W3C folder?

Jeanne: Yes, if you click on the move icon. It will tell you where it is, and who owns it.

Gregg: Are you providing access at the shared folder level?

Jeanne: yes.
... Leadership has access to everything. W3C owns the structure.
... The visibility is set for public
... For anything that is active work.
... Each of the people have permission to access and edit

Gregg: This will show up as shared with me, and you have to pull them up into your personal drive to edit them?

Jeanne: no, you should be able to edit on the W3C folder

Gregg: OK. We can help people find them if they have trouble

Rachael: We can create some instructions.
... We also try to maintain links on the wiki

<GreggVan> +1

<jeanne> +1 for linking on the wiki

Rachael: anything else on this topic?

WCAG 3: Subgroup status reports

Rachael: I will ask each group to go, but please keep it to 1 or 2 sentences

Jeanne: Equity subgroup: 2 new members
... They are bringing a broader perspective, and brought some use cases
... There are socio-economic implications
... We did not agree on a definition of equity
... We are presenting our early draft to AG on August 16

Makoto: Accessibility supported: we are documenting use cases

<Makoto> Working Document (google doc) - Accessibility Supported Subgroup https://docs.google.com/document/d/1XxzwsgWZSDh2EDqTag-nYfrqAT3b6Glpu8DGbVpTd9M/

Makoto: How different orgs in different countries are addressing the concept of accessibility supported
... Each participant is working on at least one use case
... Some other use cases will be added to the document next week
... If you know of other use cases, including accessibility supported database development please let us know

<Jem> I left the comment to the accessibility supported doc, it looked good and helped me to understand the concept better.

Makoto: We want to include these in our use cases. Thank you for your cooperation

Rachael: We will pass on issue severity for this week

Wilco: Test types: we have been updating the descriptions of the different test types
... The process one is the big outstanding one. We will work on this next week, and the open questions
... We would like to bring this to AGWG next week or the week after

<Rachael> https://github.com/w3c/silver/wiki

Rachael: The list of subgroups is on the wiki

<Zakim> Chuck_, you wanted to update on TPAC scheduling

Chuck: Leadership group is working on the TPAC schedule
... We hope to have it out next week

Rachael: Did I miss anyone?

WCAG2ICT Announcement

Rachael: Thank you to all those working on the subgroups

MaryJo: I am really close to starting the WCAG2ICT task force
... We will focus on updating the guidance to applying the guidance
... It was originally published in 2013, and based on WCAG 2
... The task force will initially focus on adding the new critieria from 2.1 and 2.2
... And address the known difficulties in applying it
... to these uses

<maryjom> https://www.w3.org/WAI/GL/task-forces/wcag2ict/work-statement#scope

MaryJo: That is the scope of work
... Anything beyond that would need to be negotiated
... and will likely not be done until a later date
... There is a deadline to try to get the first part done
... We can go through another round of updates after that
... For those that plan to participate as active participants
... The expectation is active participation in the content and reviews ...Observers: we will report to the AGWG group on a regular basis
... If you have not yet been added to the task force and want to be, contact Michael Cooper
... The survey is to help with time availability, and technology experience applying it to non web technologies
... We want to have broad experience
... The survey will be opened after this meeting
... It will be open for 1 week
... I hope to have our first meeting the last week of August or first week of September

<Zakim> MelanieP_, you wanted to comment on WCAG2ICT work statement

MelanieP: I see a lot of emphasis on new WCAG 2.1 and 2.2 success criterion in the work statement
... I want to make sure we allow for looking again at the 2.0 since a lot has changed since 2013
... I think it would be remiss if we didn't take the opportunity to accept viewpoints on existing 2.0 success criteria at the same time

MaryJo: Yes, we are focusing on addressing the new success criteria as well, as well known issues
... I welcome that input as well
... The current work statement is still a work in progress

<Zakim> Chuck_, you wanted to answer Melanie's question and to answer Bruce's question

MaryJo: As we get the work group together, this will be part of the work

<Zakim> bruce_bailey_, you wanted to ask about when "draft" comes off title of page?

MaryJo: I am not disallowing it, but I don't want to miss the mark of providing anything that the Europeans can use in their standards development

<Jem> +1 to mary for scope management

Bruce: I am confused between the work statement and the charter

MaryJo: The Charter for the AG working group includes WCAG2ICT
... But as far as the work statement for this particular task force

<alastairc> Melanie - The WCAG2ICT repo issues already includes known issues taken from the WCAG repo, which are mostly on 2.0 issues.

MaryJo: This is still a draft

Bruce: It says accepted - but is this as a work in progress?

MichaelC: I think it is an oversight that I didn't remove draft

<Zakim> Judy, you wanted to also respond to Melanie's comment

MichaelC: I am in the process of reposting it

Judy: Thank you MaryJo.
... In reply to Melanie
... I am interpreting what you are saying as: you would like revisit the potential applicability of the 2.0 things

<Chuck_> work statement of WCAG2ICT: https://www.w3.org/WAI/GL/task-forces/wcag2ict/work-statement

Judy: But not to revisit the 2.0 success criteria themselves
... I don't want it to look like WCAG2ICT is redoing 2.0
... But the mapping
... Does that make sense?

<Jem> +1 Judy

Melanie: Yes, not revisiting the success criteria themselves

Judy: Understood. I trust that MaryJo will be managing the scope carefully

<Zakim> Chuck_, you wanted to answer Bruce's question

Chuck: The workstatement: the charter was approved. The work statement - final, will be approved by AGWG once presented

Rachael: If you have questions, please reach out to MaryJo

WCAG 2.2: Changes to notes in 2.3.1 https://www.w3.org/2002/09/wbs/35422/PSE_Update/results

Rachael: From here on, we are going to cover WCAG 2.2 topics
... This will be the next hour and a half
... Gregg provided comments from him and Bern regarding 2.3.1
... They are potentially additional notes going into it

<Rachael> https://www.w3.org/2002/09/wbs/35422/PSE_Update/results

Rachael: The survey is closed
... The first part: approving the change
... The second part: how are we going to make the change, since it was present as we brought it to CFC
... I will use our typical survey process
... Starting with those that replied within the survey

Gregg: We just figured out the draft - apologies for being late
... This seems to be referring to 15 inch screens
... This makes it look out of date because of the notes
... The color space technologies have changed
... We want notes put in to say the rules still apply, but this is how you navigate in this new color space
... We also used l
... Some standards use l
... But the industry standard is to use y
... We suggest changing from l to y so it matches the other standards
... And we are here to bring information
... Whatever the group wants to do is fine with us
... We are trying to make this more helpful to users, and bring less criticism to the standard
... The goal is to help

Rachael: Looking at the survey
... Starting with those that agree with the change

<bruce_bailey_> fwiw, Y == relative luminance

Rachael: 4 agreed
... (reads from the survey)
... Did anyone that agreed want to add comments? ...Next: agree with some adjustments
... (reads Wilco's comments)
... Gregg address one of these

<scribe> ...(continues reading Wilco's comments)

Wilco: This math is complicated
... please correct me if I am wrong

Rachael: Going on to the others - Alastair
... (reading note 1)

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

Rachael: (continues reading Alastair's comments for Note b and Note c)

Alastair: nothing to add

Rachael: (reads Mary Jo's comments)

MaryJo: No further comments

Rachael: 2 something else's
... (reads Chuck's comment)

<bruce_bailey_> CSS reference pixel: https://www.w3.org/TR/css-values-3/#reference-pixel

Chuck: Pretty much what Wilco said. This is big math
... Because it is so late, I don't have time to verify

Rachael: I had the other something else
... (reads her comment)
... having read through those
... I think we should go note by note

<Rachael> themes: Note by note

Rachael: Any concerns with that approach?

Gregg: 1 reason for putting it into 2.2 - this might be the last one
... Nobody reads the Errata
... Ditto for the understanding doc - no objection
... But again comment about who reviews it
... And regarding the math: most of us will look at it, but know if the equations make sense
... If it is coming out of the working group, you want people to review it who will
... I think it is important to have it reviewed
... We can always change it if there is a bug

Rachael: I would like to go note by note

<alastairc> qv?

<Zakim> bruce_bailey_, you wanted to ask for suggestions for XYZ layperson reference

Bruce: The XYZ I don't understand. If we are going to cite that one please add lay person references

AWK: I think we need to clear up our process for what's in an Errata
... The June one is still labeled as Errata raised - it doesn't have the label switched
... This may not pass Michael Cooper's
... There is also pull request 1825, which is still open
... This may not be approved

Rachael: I see Alastair noting that clean up is the next thing

AWK: When we get to CR, we shouldn't have Errata

Alastair: There is some labeling clean up
... The open issue from Patrick is probably mislabeled
... There are some that we should be reviewing next week so they go through to 2.2
... We are also trying to get in the ones highlighted by Patrick and Steve as well

Rachael: At the end of this call we will have a conversation about where we are in the process

<Zakim> alastairc, you wanted to ask Bern about the use of angles of vision to the CSS px conversion.

Alastair: Re note 1
... Question to Bern

Note 1

Alastair: I had not realized that the previous resolution was based on the ppi size
... If we transition I would like the alternative approach Bern mentioned
... Convert the normative viewing angle to CSS pixels
... That is our best and most stable approach
... I don't understand all the math
... Is there any problem with that approach?

Bern: I did put down both as a possibility in my document

<bruce_bailey_> deciding between CSS reference pixel and something else seems important

Bern: That we keep a conserative 75 to 85 ppi, or transition to a more modern threshold
... I am ambivalent between the 2
... There is a large difference
... Videos that may have failed before will pass now - that's a concern
... Those screens listed in the 2.0 era were old, even for them
... Most of the 75-85 ppi devices - many have been retired at this point, but not all of them
... That's why I put modernizing as an alternative
... If I have to pick 1, it would be the more conservative one
... And possibly wait for a larger WCAG number to introduce another threshold

<AWK> I won't get on queue but I think that changing to 96ppi is too significant a change, and the addition to the parenthetical comment should be put into the understanding document.

<Zakim> bruce_bailey_, you wanted to mention other errata clean up -- no hurry

Rachael: What are people's thoughts on which one to use?

Alastair: AWK is saying changing to 96 may be too significant a change
... Isn't it defined as an angle for normative?

Gregg: That is correct

Alastair: Because the CSS pixel is also defined as an angle

Bern: It is in an angle (scribe missed the qualifier)

Alastair: OK, then we need a solid update

Gregg: a 10 by 7 resolution

Alastair: It is not a normative change, then, it is how people should test that normative language

AWK: My concern about making this 96 instead of 75/85
... It would potentially make things that failed before, pass
... to me, that is changing the normative content of this criterion
... I think we need more time than 2 days to evalute that and understand the impact

Rachael: Do you feel the change between the 75 and the newer value will change the test results?

Bern: It will definitely change the test results
... It is a twofold difference in pixels

Rachael: Thank you

<Zakim> bruce_bailey_, you wanted to say like two poor choices: (1) keep legacy metric (so not much of a change, but not so relevant), or (2) update to CSS reference pixel (which might be

Rachael: Bruce you may be muted
... Bruce wanted to say feels like two poor choices: (1) keep legacy metric (so not much of a change, but not so relevant), or (2) update to CSS reference pixel (which might bea big change)

Gregg: Then in understanding put something like things have changed but we are staying with the more conservative measure
... This explains why the change wasn't made, but then make the other changes
... That's another option
... The technology moved
... one of the reasons: we are using double the number of pixels on our screens
... If you are playing on an old 10 x 7 screen
... More things would fail
... But if you are following the normative language

<alastairc> Presumably double the number of pixels in the test, means that it easier to pass.

Gregg: it would make sure it wasn't twice as hard to pass on a modern screen
... However the group wants to go forward, we should think about breaking down the recommendations and notes

AWK: I would also say when I think about the number of sites that would pass or fail with or without this change, my guess is that it would be really small
... This is something that people know, generally
... I think we need to make sure we evaluate it

<alastairc> I think we've had 1 client fail it in about 20 years. (But we don't do much in broadcasting.)(

AWK: This may be the least often violated SC we have
... It can have an impact that is immediate

<bruce_bailey_> +1 to AWK that we are talking about very few pages at this point in time

AWK: So it doesn't bother me to keep it more conversative

Katie: We do have to acknowledge that things have changed
... And that we will do a greater inspection for the next release
... We can't pretend it doesn't exist

<SuzanneTaylor> +1 to AWK Also, shouldn't it be more conservative, considering that user behavior is changing

Rachael: review this straw poll

<Rachael> straw poll: 1) Keep existing 75-85 ppi and change in WCAG 3, add information to understanding or 2) use the modern 55,225 css value and accept change in results

<Zakim> GreggVan, you wanted to say agree with Andrew - and those that fail usually fail both

Gregg: I agree with Andrew
... Those that fail will usually fail the old and the new

Alastair: I am not too concerned which kind of size
... If we don't do that conversion we will get people raising issues in the repo
... If the note doesn't match the normative text
... If there is a way we can head those off it would make me happier

<Zakim> SuzanneTaylor, you wanted to ask if this new material takes into consideration that users are not sitting an arms length from their devices

Suzanne: Is this new material taking into consideration users are no longer sitting at arm's length from computers

Bern: I have done some analyses
... Computer screens tend to be viewed at the closest and with the widest viewing angle
... Televisions are on the low end since the distance is so far
... More risky is VR and AR headset
... The CSS pixel specification is a little bit loose
... Each device states which conversation they are using
... Most modern devices are within a small percentage of being 96 at typical viewing distances
... Yes, the device manufacturers bring into account their typical viewing distances in their definition of what a default pixel is

Suzanne: did you look into how children use iPads and tablets?

Bern: I did not.

<alastairc> Gregg - from my kids, yes!

<bruce_bailey_> scribe: bruce_bailey

<Zakim> GreggVan, you wanted to say oh -- forgot - this applies to more than web and it does fail a LOT in other contexts

<bruce_bailey_> GreggV: For viewing distance -- are kids watching videos or playing games? ...

<bruce_bailey_> ... agree that rare nowadays for web pages to fail, but we are still seeing issues with other devices

<alastairc> If the area is larger, doesn't that make it easier to pass?

<Rachael> straw poll: 1) Keep existing 75-85 ppi and change in WCAG 3, add clarification and explanation to understanding or 2) use the modern 55,225 css value and accept change in results

<bruce_bailey_> ... concern that with Access Board adopting WCAG standards and applying to non-web pages, could be concern for other hardware

<AWK> 1

<Ryladog> 1

<bruce_bailey_> Rachael: back to straw poll

<Wilco> 2

<alastairc> Prefer 2 but can live with 1

<GreggVan> 2

<Chuck_> 2, no objections to 1

<maryjom> 2

<laura> Prefer 2 but can live with 1

<MelanieP_> 1

<GreggVan> prefer 2 but can live with 1 if higher pixe info is in Understanding WCAG

<jaunita_george> 2

<Chuck_> 8 2's, 3 1's

<SuzanneTaylor> 1

<Chuck_> now 4 1's

<bruce_bailey_> Rachael: can 1s accept 2 ?

<Ryladog> yes

<SuzanneTaylor> yes

<AWK> I think that this will be the first non-errata change to WCAG 2.0 SC

<SuzanneTaylor> +1

<bruce_bailey_> Melanie: My concern is the how quick this has come up, and time limit for people to read. Might be setting precedent here.

<SuzanneTaylor> (to MelanieP)

<bruce_bailey_> Rachael: Could you accept the change if it goes through some (unspecified) process?

<Zakim> Chuck_, you wanted to ask if there are any 2's that cannot live with 1?

<bruce_bailey_> ... Are you more concerned for present process?

<Wilco> I'm okay with 1

<Zakim> GreggVan, you wanted to say in understanding -- we should explain that it has not changed normatively -- it is still angle of view. we are just alerting people to the fact

<Chuck_> I'm ok with 1

<bruce_bailey_> Melanie: My larger concern is that this feels rushed.

<bruce_bailey_> Chuck: Most 2s can live with 1 -- any 2s care to speak against 1?

<AWK> If nothing is changed why did Bern say that some content would now pass?

<bruce_bailey_> GreggV: By putting 96 in, we are not changing requirement -- we are highlighting that technology has changed.

<bruce_bailey_> ... If we take note out, then criteria the same, but Note then misleading.

<bruce_bailey_> Melanie: I heard that testing at 96ppi could be false positive (or vice versa)

<bruce_bailey_> GreggV: Risk is failing something that when you should be using updated metrics.

<bruce_bailey_> Alastair: Update provides for more smaller pixels because angle is normative metric...

<SuzanneTaylor> I would like to change my response to Can you accept 2, to No (We need new user research for this, not just changed math)

<bruce_bailey_> Your are taking pixel measurement -- so smaller area as measured by CSS reference pixel...

<SuzanneTaylor> +1 to alastairc

<Rachael> +1 to keeping the current text and adding addiitional information to the note that helps people understand the new context

<Zakim> GreggVan, you wanted to say we are comparing CSS pixels with Screen pixels

<bruce_bailey_> ... safest option is to keep pixel example with caveat -- developers less likely to cause seizures...

<bruce_bailey_> ... if developers want to cut it close, they can do the updated math.

<bruce_bailey_> GreggV: We are comparing two different types of displays, very early metric assume 1024x716 screen CRT...

<Zakim> Chuck_, you wanted to say MelanieP convinced me, and I'm now a 1

<bruce_bailey_> ... but if person assumes modern display at 96 ppi that can be twice as many pixels.

<Rachael> straw poll: 1) Keep existing 75-85 ppi and change in WCAG 3, add clarification and explanation to understanding or 2) use the modern 55,225 css value and accept change in results 3) Keep existing text and adding additional clarification to note about change in technology then clarify further in understanding

<bruce_bailey_> Chuck: Lots of conversation, I am switched to 1 based on conversation Melanie raised.

<Wilco> 2, assuming we errata this for 2.1 and 2.0

<Chuck_> 1

<bruce_bailey_> Rachael: new poll, and additional option.

<AWK> 1 or 3

<SuzanneTaylor> 1

<alastairc> 2, 3, 1 in that order of preference. Overall happy it gets an update.

<Chuck_> I'm ok with 3

<Ryladog> 1 then 3

<maryjom> 2,3,1 in that order

<MelanieP_> 1 or 3

<laura> 1, 3, 2

<bruce_bailey_> Chuck: Seems like 1 , then 3, then 2

<Detlev> not close enough to the topic to judge

<bruce_bailey_> Rachael: 2/3 not live with 1 ?

<Rachael> Can anyone in the 2s or 3s not accept 1?

<Wilco> Can live with, yup

<Rachael> Can anyone in the 1s and 2s not accept 3?

<AWK> can live with anything, just think 2 is a mistake

<Chuck_> I can accept 3

<bruce_bailey_> Racheal: Seems like 1 or 3 best option.

<bruce_bailey_> Alastair: Just note, this is small update with Notes.

<bruce_bailey_> ... Updating Understanding document seems like good path

<bruce_bailey_> Rachael: Other comments? Or we can have draft resolution.

<Rachael> draft RESOLUTION: Keep existing 75-85 ppi and change in WCAG 3, add clarification and explanation to understanding

<Chuck_> +1

<Ryladog> +1

<SuzanneTaylor> +1

<laura> +1

<alastairc> +1

<MelanieP_> +1

<Wilco> 0

<jaunita_george> +1

<AWK> +1

<maryjom> +1

<JenniferChadwick> +1

<bruce_bailey_> Rachael: Anyone to speak against? Wilco?

<bruce_bailey_> Wilco: It is okay.

<bruce_bailey_> Rachael: I have some concern with tying to pixel resolution in survey.

<Rachael> These calculations use the more conservative resolution of 75-85 ppi, which is lower than the nominal CSS pixel resolution of 96 ppi in CSS specifications

<bruce_bailey_> ...Alstair noted CSS spec is not likely to change.

<alastairc> no concern

<Chuck_> +.75

<SuzanneTaylor> +1 to Rachael's edit

<bruce_bailey_> Bern: I cannot see final proposed edits, but I am not seeing any substantial changes to what I proposed.

<bruce_bailey_> Chuck: Are we proposing mention of CSS reference pixel?

<Rachael> draft RESOLUTION: accept: "These calculations use the more conservative resolution of 75-85 ppi, which is lower than the nominal CSS pixel resolution of 96 ppi in CSS specifications."

<Chuck_> Then I add +.25 to my vote

<Chuck_> 1

<Chuck_> +1

<jaunita_george> +1

<SuzanneTaylor> +1

<maryjom> +1

<bruce_bailey_> Bern: Seems reasonable to me, later we can update Understanding.

<laura> +1

<Wilco> +1

<MelanieP_> +1

RESOLUTION: Keep existing 75-85 ppi and change in WCAG 3, add clarification and explanation to understanding

RESOLUTION: accept: "These calculations use the more conservative resolution of 75-85 ppi, which is lower than the nominal CSS pixel resolution of 96 ppi in CSS

<bruce_bailey_> Rachael: Any other concerns?

New Note A

<Rachael> Content should be analyzed at the largest scale at which a user may view the content, and at the standard zoom level of the user agent. For example, with a video that may play in an area of a web page and also at full screen, the video should be analyzed for risks at full screen. When determining the size of the “full screen” for analysis purposes, a safe assumption to use is that the short dimension of the full screen represents a

<Rachael> 25-degree viewing angle. This metric works well for computer screens, and is even safer when used for content displayed on TVs and smart phones because of typical viewing distances.

<bruce_bailey_> Rachael: Other comment was that 2nd half was not clear.

<bruce_bailey_> Bern: In original document, we included a table with ergonomic metrics, 25 degree was intermediate...

<bruce_bailey_> ... samples were precise, not 1024 by 716 -- I prefer viewing angle...

<bruce_bailey_> ... we picked something intermediate, 25 degrees tall, maybe 35 to 45 degrees wide...

<Zakim> alastairc, you wanted to outline reasoning for removing the second half

<bruce_bailey_> otherwise reader has make some decisions about what they are assuming.

<Ryladog> me/ says on a VR viewer the fixes a angle but very close to user

<bruce_bailey_> Alastair: Page authors are comfortable with full screen choice and then infer worse case for number of pixels...

<bruce_bailey_> ... it is good note, but otherwise authors have to take a worse case scenerio.

<bruce_bailey_> Bern: Agree that developer want specific pixel dimensions...

<GreggVan> it is not how close something is -- but how close it VISUALLY is and how much of an angle any content uses

<Rachael> straw poll: 1) Add full note to main doc 2) add the note to understanding doc 3) do not add at all

<bruce_bailey_> ... so we probably should keep working on Understanding...

<AWK> Note 2 is all useful info but should be understanding content, IMO.

<alastairc> 2

<SuzanneTaylor> 3

<jaunita_george> 2

<Rachael> 2

<AWK> 2

<maryjom> 2

<Chuck_> 2, ok with 3

<Ryladog> 2

<bruce_bailey_> ... want to be clear about worse case assumptions for developers, will need some more time to write up.

<Wilco> 2

<laura> 2

<MelanieP_> 2 or 3

<bruce_bailey_> Rachael asks Suzanne about 3.

<AWK> If understanding document it can be easily updated at any time.

<bruce_bailey_> Suzanne: Don't think it should go in when we do not have research or data on how kids using tablets.

<AWK> yes, easy relative to changing the normative doc :)

<bruce_bailey_> Rachael: Proposal is to add something similar to Understanding now, add more later when we have research.

<bruce_bailey_> Suzanne: I don't think it should be added as-is when we are missing important use case.

<bruce_bailey_> Rachael: What would you want added?

<Rachael> draft RESOLUTION: Add note to understanding document and bring back for further discussion and full approval

<bruce_bailey_> Suzanne: I don't have Note text to propose.

<alastairc> +1

<bruce_bailey_> Suzanne: I am looking for further discussion before moving ahead.

<Rachael> draft RESOLUTION: Add note to draft understanding document for further discussion and full approval

<laura> +1

<jaunita_george> +1

<SuzanneTaylor> +1

<Wilco> +1

<Chuck_> +1

<maryjom> +1

<Ryladog> +1

RESOLUTION: Add note to draft understanding document for further discussion and full approval

New note B

<bruce_bailey_> Bern agrees to keep helping to draft updated Understanding.

<bruce_bailey_> Rachael reads from survey.

<bruce_bailey_> Rachael start with what is needed for content?

<bruce_bailey_> Alastair: My suggest for start of it is for author, adding sRGB content. Good idea for starting sentence in note about that assumption.

<bruce_bailey_> ... rest can go into Understanding.

<alastairc> Note of: "Where video content is provided in color spaces other than sRGB, the version provided with the highest dynamic range should be tested." Then the rest in the understanding document.

<Rachael> straw poll: 1) Add note to document 2) Add first sentence to document 3) add all to understanding 4) do not add

<bruce_bailey_> Alstair: Yes, first sentence about color space sRGB, goes to Note. Mention HDR or there, but rest to Understanding.

<Wilco> 3

<Rachael> straw poll: 1) Add note to document 2) Add first sentence to document and the rest to understanding 3) add all to understanding 4) do not add

<jaunita_george> 2

<alastairc> 2, 3, 1

<AWK> 2 or 3

<Chuck_> 2, 3

<Rachael> 2, 3

<maryjom> 2 or 3

<laura> 2 or 3

<JenniferChadwick> 2,3

<MelanieP_> 3

<Ryladog> 3

<Wilco> yeah, 2's alright

<Ryladog> can live with 2 if it says "See Understanding"

<Chuck_> bruce: Who raised question about hdr vs srgb?

<Chuck_> alastair: That's note b.

<Chuck_> bruce: someone was concerned about how it was written up.

<bruce_bailey_> Bruce asks about who raised in survey?

<bruce_bailey_> Alastair: That was my suggestion.

<Ryladog> See above

<bruce_bailey_> Rachael asks 3s if they are okay with 2. Melanie asks to read again.

<Rachael> For cases where output luminance is known, or for color spaces other than sRGB, the industry standard definition of a general flash is a change in luminance of 20 cd/m2 or more where the darker image is below 160 cd/m2. [ITU-R BT.1702

<Ryladog> And link after setence can live with 2 if it says "See Understanding"

<bruce_bailey_> Rachael clarifies that this is addition to 2.2 Note.

<bruce_bailey_> Alastair: From conversation with Bern, HDR warrants mention in 2.2 because it can flash brighter...

<bruce_bailey_> ... but additional background can be added to Understanding.

<bruce_bailey_> Bern: This was long, but included cite to change of luminance and ITU standard in different domain, HDR, where ITU references uses different metric (Nicholson)...

<bruce_bailey_> ... That metric is needed for things light lightning and not practical for video on television and similar...

<bruce_bailey_> ... so can apply to HDR so included for completeness.

<jaunita_george> Yes

<bruce_bailey_> Meanie: I am comfortable with adding to Understand, so that is my choice 3.

<Rachael> draft RESOLUTION: Add the Note B to understanding

<Chuck_> +1

<laura> +1

<maryjom> +1

<MelanieP_> +1

<alastairc> +0.5, would prefer some reference for testing purposes, but can live with.

<Ryladog> +1

<Wilco> +1

RESOLUTION: Add the Note B to understanding

<Rachael> For short clips that might be looped (such as GIF animations), the content should be analyzed while looping.

<bruce_bailey_> Rachael: Two notes left.

<Wilco> +1 to understanding doc

Note C

<bruce_bailey_> Rachael: Trend has been to add material to Understanding.

<Rachael> draft RESOLUTION: Add note C to understanding

<alastairc> +1

<Wilco> +1

<Ryladog> +1

<maryjom> +1

<jaunita_george> +1

<MelanieP_> +1

RESOLUTION: Add note C to understanding

<AWK> +1

NOTE 3

<alastairc> Most of the math is there already

<bruce_bailey_> Rachael: Note 3 has a lot of dense math

<bruce_bailey_> Rachael: Wilco proposed changes in both places.

<bruce_bailey_> Alastair: New part is just the red in the middle. This was already a dense note.

<alastairc> The current working definition in the field for "pair of opposing transitions involving a saturated red" is: *** a pair of opposing transitions where, one transition is either to or from a state with a value R/(R + G + B) that is greater than or equal to 0.8, and the difference between states is more than 0.2 (unitless) in the CIE 1976 UCS chromaticity diagram. [ISO 9241-391]

<bruce_bailey_> Alastair: look for part after three asterisks / stars ****

<bruce_bailey_> Bern: Point of change in general is an ISO standard 92431

<bruce_bailey_> ... only other standard that describes saturated red...

<bruce_bailey_> ...proposal is align with this ISO standard. What is in 2.1 and 2.2 is short line, but different than ISO

<bruce_bailey_> ... technically WCAG standard could be reference between two very similar reds -- which is not intended

<bruce_bailey_> ... ISO ensures colors have significant difference...

<bruce_bailey_> ... heavy math is from me trying to explain the difference... ISO just makes cite to chromicity diagram

<bruce_bailey_> ... we could loose the math -- move that to Understanding -- and have cite similar to ISO

<GreggVan> back

<bruce_bailey_> Rachael: Chair hat off, could this change testing results?

<bruce_bailey_> Bern: Yes, in that samon/red flash might now pass using newer ISO reference.

<alastairc> Is salmon to red a problem for users?

<bruce_bailey_> ... I would note we are missing older paper

<bruce_bailey_> GreggV: We have video, but not paper.

<bruce_bailey_> Rachael: Pausing this discussion, will have to survey...

<bruce_bailey_> ... we have had a couple issues raised during CFC which chair want to address for a couple minutes...

<bruce_bailey_> ... we are going let CFC deadline come -- so not a pass -- and revisit

<bruce_bailey_> ... plan is to revisit with shorter CFC deadline

<GreggVan> +1

<bruce_bailey_> Racheal: So we have a new CFC, just a couple days, but more discussion.

<bruce_bailey_> Bruce: my earlier question was about errata, that can wait

<bruce_bailey_> GreggV: Errata should all be address, collapsed into CFC

<Ryladog> +1 to Gregg

<bruce_bailey_> Alastair: Question is confusion about 2.1 errata which go into 2.2 on it's face.

<bruce_bailey_> GreggV: Thanks groups for inclusion of complicated topic on flash and red flash threshold.

- DRAFT -

AGWG Teleconference

09 Aug 2022

Attendees

Contents

New members and topics

Announcements

WCAG 3: Access to WCAG 3 Google docs https://github.com/w3c/silver/wiki#subgroups

WCAG 3: Subgroup status reports

WCAG2ICT Announcement

WCAG 2.2: Changes to notes in 2.3.1 https://www.w3.org/2002/09/wbs/35422/PSE_Update/results

Note 1

New Note A

New note B

Note C

NOTE 3

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output