Meeting minutes
https://
<Lauriat> Please sign up to scribe: https://
<Lauriat> Also we need a scribe for today!
Quick update on Error Prevention next steps
Chuck: Notes that chairs are aware there have been stresses between Silver and AGWG -- and chairs are working on how to bring us all forward togewther
Chuck: So, requesting everyone hold for the moment
Placeholder guidelines and how we incorporate into the draft
Lauriat: Fleshed out enough to give an indication of what WCAG3 might look like
Lauriat: In the expectation and in response to the request that this is helpful
Lauriat: drafted based on the 2.x to silver map
Lauriat: does not include 2.2
Lauriat: these are "placeholder" guidelines
Lauriat: some are pretty solid, and others not
Lauriat: multimodality version of 2.4.5 ...
Lauriat: clear lang gives us something to point to
<Chuck> janina: Note on conformance, when we agreed that next draft would have user generated, we would flag "that" in there. Same expectation of what we presented on media a few days ago. No commence since. May emerge more.
<Chuck> janina: media, captions, described media. Portions such as text alternatives, we'll treat differently than the web publisher. Does anything drafted encompass media or user generated?
sajkaj: Asks about marking user generated (and media) ...
Lauriat: Some would be media ...
Lauriat: believe user gen should be kept separate for now
Lauriat: when we put this in a draft, there will be the framing caveat -- i.e. a direction, not a finished product to implement
Lauriat: the point for now is the shape of things, not implementation ready content
<Zakim> jeanne, you wanted to remove strikethroughs for screen-reaader users and to ask if members of Conformance Options could put in notes in this outline?
jeanne: Thanks Shawn, because it's lots of work and very helpful
jeanne: suggests removing the strikethroughs as it's a complication for screen reader users
jeanne: Asks Conformance Options people to annotate where things might fit by way of notes
Lauriat: OK to cleanup
Lauriat: Not sure annotation from Conformance is yet helpful? If it would be helpful to get a sense ...
Lauriat: suggests ed notes in the groupings
Lauriat: the list at the bottom of the doc is purposefully not linking to anything -- the grouping list up top does link
jeanne: agrees
<Chuck> janina: Should I look at groupings and put in editors note?
<Chuck> jeanne: I'll work with you Janina if you'd like.
<Chuck> janina: I was looking at it this morning, and seeing the actions that need to be taken.
<Chuck> jeanne: I can help with that too.
<Chuck> back to you janina
Lauriat: notes each grouping has a struct; many have no methods yet
Lauriat: methods may be the place for the note--or top level bullet
JakeAbma_: Confirming this is placeholder guidelines?
JakeAbma_: some more related to specific user need; others more like struct/framework; others like outcomes ...
JakeAbma_: seems they are proper goals but could be seen differently
JakeAbma_: seems it fits one way; but may not be our eventual approach
JakeAbma_: user needs had a similar challenge and came up with a different set of categorizations
JakeAbma_: including apis -- nav, various tech sets
JakeAbma_: tried to have a set that felt like they belonged together
JakeAbma_: sdo asking as an open question; work from these? Or should we see what sets might come out if we think about it that way?
Lauriat: re "is the list?" no,
Lauriat: it's strictly what wcag3 might look like strictly migrating from 2
Lauriat: this is to give an idea as we go through the process of migrating
Lauriat: this list will be replaced eventually
Lauriat: hopefully also helps with conformance work
Lauriat: it's been some time since we had a wider conversation as Jake is suggesting from user needs
Lauriat: we want to cary core principles into 3, but not as an architecture
Lauriat: i.e. the perceivable, etc
Lauriat: we should be able to find those 4
Lauriat: I'm inclined to hold off getting into the specifics until user needs are more fleshed out and understood
Lauriat: did think we could start working through taking the intersections from user needs to give us a sense of scoping
Lauriat: so similar to user needs, but used differently
<sajkaj> s/differently from 2/
Wilco: asking why this list as starting point?
Wilco: if we know it's not where we will end up
Lauriat: mainly to use a pass of interpreting user needs and expanding some ov 2 coverage like sc around text line length
Lauriat: expanded to customization
Lauriat: overall management, overall customization
Lauriat: to see how well we've covered certain intersections and where coverage is missing
Lauriat: that was my thinking in any case. If it doesn't help, we'll try something else.
Wilco: Not opposed, just wondering
Lauriat: q for jake ...
Lauriat: before intersections I see lots of direct 2 notes; but some that aren't
Lauriat: is it just areframing of 2 SC's?
JakeAbma_: hope i understand the question ...
jake you're looking at intersection of functional and user needs? Yes?
Lauriat: yes
Lauriat: example C7
Lauriat: oops, let's try e7
Lauriat: notes allows for brightness adjustment
JakeAbma_: allow for making brightness adjustments
<Chuck> janina: Brightness adjustment, very last apa call on an api, gave horizontal review approval. API for auto-adjusting brightness based on lighting conditions. Should we have not signed off? Is there some level of gradience that would move away from the mean?
<Chuck> janina: Is it a factor we should consider in the api?
<Chuck> shawn: Great question, but not for today.
<Chuck> shawn: some note somewhere, I asked specifically to see where the line item came from. If it came from one of the existing sc's or some other work.
sajkaj: Notes apa signed off on a brightness api and asks whether it should be user adjustable?
<Chuck> shawn: The answer was that it came from another row that has specific needs called out.
Lauriat: need to capture that somewhere ... not today's discussion
<Chuck> back to janina for scribing.
Lauriat: is that correct?
jake yes
Lauriat: think we can use this mapping spread sheet to map out ...
Lauriat: anything not text needs text alternative for example
Lauriat: provides braille translation?
janina suggests the AT is responsible for braille, no?
Lauriat: provides support for non binocular needs
Lauriat: don't believe we have coverage
Lauriat: inclined we don't have this
Lauriat: asks for sanity check at this point
Wilco: having a hard time following; asks for screen share?
SuzanneTaylor: wanted to suggest intersections not well understood by a11y industry -- we need some way to mark those
+1 to Suzanne because APA will need that info
SuzanneTaylor: there also may be no way to prove some assertions
Lauriat: agree it would be helpful and believe we will uncover a lot of those
+1 to shawn
SuzanneTaylor: still two different categories; somethings user have told us; other things are ideas we've come up with but have no user validation for
SuzanneTaylor: we need to avoid guidelines that we don't need--that weren't substantiated
Lauriat: believe we can have two versions of this doc for those two purposes
SuzanneTaylor: agrees
JakeAbma_: worries about keeping two representations sync'd
jake: concerned that we not lose track and get others checking; michael proposed a db
Z access!
Lauriat: glad this has been already thought about
Lauriat: notes row 4 as more detailed overall needs
Lauriat: again, trying to see what's covered and what isn't
Lauriat: will eventually help with more than one guideline in the same intersection -- whether multiple could be amalgamated or not
Lauriat: notes text rendering customization as related
Wilco: surprising that text needs to be available; but there's aria-hidden
Lauriat: yes, exactly
Lauriat: brl translation is more implied
Lauriat: inclined to replace with 'AT can access'
<Chuck> janina: Interesting, not sure if it's the time to discuss. The braille one troubled me. ...created a problem for braille, was too focused on TTS user. I don't know how we keep those separate. That may be the issue.
janina notes that aria created problem for brl by focussing too exclusively on tts users
Lauriat: agrees there's much to look at here with use cases
Lauriat: notes zooming in/out -- think it's covered even though there's much to it
Lauriat: so, maybe -- we should check
Lauriat: color not as only means--covered
Lauriat: luminence contrast -- much done, but more to do
Lauriat: things that need distinguishing
Lauriat: the work of building the guidance will help us frame it appropriately
Lauriat: so, a maybe
+1
Lauriat: many instances of "allow for customization"
Lauriat: majority may be covered; but customization brings in more users
<Chuck> janina: We want to think about api's from that perspective, I believe.
janina notes we want to think about apis from that perspective
Lauriat: asks if this has been helpful
+1K
<SuzanneTaylor> +1
<JakeAbma_> +1