<Chuck> meeting: AGWG-2024-05-14

<alastairc> agenda order 1,3,4,6,8

<scribe> scribenick: hdv

<alastairc> scribe:hdv

<bruce_bailey> Happy GAAD

<bruce_bailey> https://accessibility.day/

WCAG2ICT Coming

Chuck: this is a preannouncement on WCAG2ICT

maryjom: WCAG2ICT is close to publication, this week I'm hoping we'll approve the last content changes to go into editor's draft, then the TF will review for a week
... what's changed: we've added all of the WCAG 2.2 criteria and definitions, and addressed public comments from public working draft and AGWG members
... please keep an eye out for that
... this will be the next to the last publication, we hope
... we think it is pretty much ready
... hopefully next publication will be final note

Chuck: what I'd like this group to do… if you're interested in reviewing in WCAG2ICT, we're looking to keep the timelines on schedule

Publication Approach Subgroup Mid-Brief

Chuck: we have a subgroup publication approach that has been working, they've offered to do a mid brief today

<bruce_bailey> https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/

wendyreid: we ended up having to restart the subgroup, we're now two weeks in our cycle (not mid way)
... we had two very good meetings
... we don't have a lot to report yet as we've technically just started
... we looked at the research done on WCAG3 and the working draft, trying to figure out how to chunk things up to shippable segments
... we're still in brainstorm mode
... in a couple of meetings we should have more to report on

Chuck: is the timing and participation going well now that cadence was decided?

wendyreid: yes now we have more regular attendance and some more people involved
... we changed date and time, we meet Thursday morning 9am ET

<Zakim> bruce_bailey, you wanted to discuss home page ?

Focus visible subgroup initial brief

<Rachael> Slides: https://docs.google.com/presentation/d/1cy4olW2lIgloq5bgi_om3ize0gSq5ASZX71WbtIoMko/edit?usp=sharing

[alastairc shares slides on screen]

Rachael: we started by discussing the different related focus appearance requirements
... on slide 2 you can see the set we started with
... then we looked at the researched that had been pulled together
... for context, this is the first subgroup doing guidance work
... we started with focus must be visually indicated and is visually discernable. Slide has a link to the scratchpad

<alastairc> Full scratchpad: https://docs.google.com/document/d/1IgNr6WAd9ovk7t4sMrrZkLJzsFBDROOpw3i1oCxlCVQ/edit

Rachael: one example is a focus indicator that is visually between two links but equal distance from both so not clear which it indicates about
... we moved it up to the guideline level
... we added a draft decision tree, very similar to the alt decision tree we did in this group

[Rachael reads the slide with “guideline for the point of interaction must be visually indicated”]

Rachael: there is a lot more exploration needed between contrast changes and area
... we also started drafting definitions for things
... so we've been through one cycle of writing, that we're not refining and flushing out
... we also got to a separate but related outcome
... did I miss something that needs to be added here?

alastairc: I think the adjacent colours bit is quite tricky, needs more exploration
... we'll need some difference in how that is stated
... might look quite complicated if we look at different requirements for line indicator vs background indicator… we can look at that and hopefully it can make the main requirement simpler
... we tried to capture everything first and hope to make it simpler afterwards

Chuck: I have no different number to offer re surface area of the component and % that needs to be visible… how did the group come up with those numbers?

Rachael: currently a line in the sand

dan_bjorge: sounded like what we already tried with current focus appearance requirements, but found it was too deterministic to test
... am I missing something?

Rachael: we are exploring something that we've talked about in WCAG 2.2, think that's a good thing
... the reason we're looking at this is that we take something that the group did recently talk about, so that we can see how it fits in the WCAG 3 realm
... also, reminder, not everything that ends up in 3 / this list is a requirement, some might be best practices

<Zakim> mbgower, you wanted to say that the last text statement on pointer will cause the standard behaviour of buttons to fail

<Rachael> Outcome: When located over an interactive element, the pointer location and interaction type must be visually indicated

mbgower: would you be able to share the sentence on the pointer again?
... I think that would fail basic behaviour for buttons right now?
... so think we need some language re UA default there

Chuck: the subgroup will note it down and take it back to that group

<Rachael> +1 to noting that.

Graham: the browser defaults work in some scenarios but not in others
... eg if I make a dark button on light background, browser defaults are useless… the second you change colors and stuff the browser defaults often fail

alastairc: I think we are trying to explore how we can take the complexity of this problem and use a decision tree to make meeting it and testing it easier than we managed to do in WCAG 2.2

<Graham> https://codepen.io/GrahamTheDev/pen/PovqKVO here is an example of browser default failing

alastairc: think what we have at the moment… at bronze level the default indicator is deemed okay; then if you've overriding that and making it more complex, you'd get to different level… this might end up being a bit easier than 2.2 was

<Zakim> Rachael, you wanted to raise a question about browser defaults

<scotto> browser _have_ gotten better with focusable defaults. chromium browsers account for light and dark backgrounds by having a dual focus ring (black and white). but firefox, for instance, has a blue focus indicator all the time.

Rachael: if we have criteria for what a good indicator looks like, is there an opportunity to talk to browser vendors to see if they could implement that?

[big +1 to having this as defaults in browsers, which exist to some extent as scotto says]

Graham: where can we add suggestions?

<alastairc> And whether we should assume users who have a need will use the best UA for that need...

<kirkwood> when does the group meet?

Rachael: maybe at the bottom of the scratchpad
... we are meeting on Mondays at 10am ET

ACT Rules format 1.1 https://github.com/w3c/wcag/issues/3616

[Chuck shares his screen]

<Chuck> https://github.com/w3c/wcag/issues/3616

<Rachael> Please add comments about focus indicators at https://docs.google.com/document/d/1IgNr6WAd9ovk7t4sMrrZkLJzsFBDROOpw3i1oCxlCVQ/edit#heading=h.yqx6p9b261ko

Chuck: ACT are looking to put out the first working draft of their rules format for 1.1
... looks like there's nobody on the call to add context, I'll add some
... accessibility support and assumptions section are now subsections of “background”

[Chuck reads linked issue description https://github.com/w3c/wcag/issues/3616]

Chuck: this kicks of the 5 day review period

<Chuck> hdv: The issue that it's being shared is 2023.

<GN015> Is it 5 working days or 5 calendar days?

<alastairc> Working days

<Chuck> Draft RESOLUTION: Approval to move ACT-Rules Format 1.1 FPWD for review to CFC

alastairc: I don't think we can resolve, because we're bringing this to people's attention right now and they haven't had a chance to look at it
... so please everyone have a look at this issue, we'll do a CFC next week

<dan_bjorge> The first we've seen of it is 5 months ago, no?

Chuck: yes it was a while ago

<Nayan> We need more time to review this

alastairc: it has gone around

Accessibility Suported https://github.com/w3c/wcag3/discussions/53#discussioncomment-9353131

Chuck: Alastair drafted a proposal recently and now has a second draft proposal

alastairc: yes, have made some updated based on discussion last time
... proposal was to vary the accessibility supported requirement by level
... so bronze level methods can assume AT supports the requirement
... so they'd be fairly generic
... at the silver level, methods would include information on AT compatibility
... if authors don't follow the methods they'd need to do their own testing
... authors or regulators would need to set what user agents and AT would need to be tested for
... one of the original requirements for this topic was, if an AT had a bug for more than 2 years or if they refuse to update it, an author could claim an 'exception'
... essentially they'd say they would ignore that requirement

<Zakim> Chuck, you wanted to ask about exceptions

Chuck: who are the arbiters to define that a bug has existed for > 2 years?
... some companies are pretty ambiguous re commitments to address bugs

alastairc: so you're saying… for example hypothetical Yedi Voice Tech doesn't support file upload, and hasn't for 40 years, we continue to use a method X, even we know it isn't supported in that particular voice tech

dan_bjorge: agree with the question… also wonder what's the boundary between browser and AT… and between a bug and a feature?
... I think conceptually this looks ok to me, but the exception makes me nervous and it seems not specified well enough

scotto: I am aware of some software that some consider AT, but then that software publicly said it doesn't consider itself AT… 
... re ARIA there can be instances where people might consider there to be issues with AT but it's really a browser issue
... there's all sorts of misinfo and misunderstandings that people have on that

<bruce_bailey> browser v AT bug is interesting

scotto: I agree with dan_bjorge, this is not a bad concept/idea, but there are a lot of exceptions that aren't easy to resolve

Graham: we also get into the point of… if I tested with JAWS 16 on browser X but then it doesn't work on the other… as a tester you'd need hundreds of tests to just pass Silver… if I wrote something to spec surely that should mean it passes
... I worry this becomes a mammoth

<Zakim> alastairc, you wanted to say it would an exeption to things which don't meet our published methods.

Graham: are we going to provide information on what's supported or not or does everyone have to do their own testing to show they comply with Silver

alastairc: everyone's focused on the exception… if I deleted that would everyone be happy?
... what we're saying… bronze level, which we anticipate is equivalent to WCAG 2 AA… you can assume it works. If you're going beyond the baseline regulative level, you get into 'more testing' territory

<kirkwood> seems the purpose is not to be adopted by regulatory entities. but more for giving best practices?

alastairc: you can use a published method in Bronze or Silver… and then if you have publicly available information re it doesn't work or isn't going to work, you can claim we can't help it…

dj: I love the general idea of the exception

<alastairc> +1 on the subtle incentive thing

<Zakim> Chuck, you wanted to say if we are focused on the exception, the rest of the content may be pretty good?????

Chuck: so far the group seems focused on the exception, but not on the rest of the content
... please let us know if you have concerns elsewhere, or if you like it

<alastairc> scribe+

<alastairc> dj: The rest of the proposal seems good.

<alastairc> scribe-

dan_bjorge: how do decide which specs can be assumed to be trusted?

alastairc: am proposing we do it like Techniques at the moment… we publish methods that we say support this outcome. That method could be saying 'use this ARIA pattern' and be technology specific or could be more general

<Zakim> kirkwood, you wanted to say it seems removing regulatory implementation and support of guidance and moving toward qa/qc testing framework

<julierawe> present_

kirkwood: this is great. I am concerned this dilutes things a bit…not something that regulations can be written around, which is fine…

Graham: we could add a number of devices or assistive tech you have to test on… rather than which one, say an x amount of a specific type
... that way you could pick the one's most relevant for your area
... it seems difficult for someone to get to Silver level that isn't a giant corporation

<Zakim> alastairc, you wanted to comment on the regulatory point, not sure why it wouldn't be? At bronze at least

dan_bjorge: maintaining a support table is a lot of work, that alone would probably require more work than the WCAG 2 TF work… would be good to pull in an invited expert.

<Graham> What Dan mentioned: https://a11ysupport.io/ - they struggle to even cover what is supported

alastairc: totally agree, have been involved in that kind of project before, it's a nightmare to keep track
... on the assumption WCAG 3 is in a content management, we have tags for methods and would have a tag for each major version we need to keep track of
... we're quite conservative re putting in Technique before it has a lot of support
... but managing this in a CMS and using a tagging approach might allow us to be a bit more flexilbe
... I don't think it's a lot more than we currently do

<kirkwood> to Alastair, LOE. tracking of AT. who is responsible? he has legal determination of support, W3C?

alastairc: re John's point re regulation… not sure if it would be more difficult to include in regulation, in relation to what we currently do?

<bruce_bailey> I don't agree that requiring end-user testing is a poison-pill to regulators. In U.S., under ADA, consent decrees / settlement agreements often include end-user testing.

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

<alastairc> qq+ kirkwood

scribe-

<kirkwood> would that not mean the technology would have to be tracked by an entity?

<ljoakley1> scribe+ LoriO

<alastairc> scribe: ljoakley1

<Zakim> kirkwood, you wanted to react to Chuck

<jtoles> Sorry, stepped away for a min. I can scribe if needed

<Zakim> bruce_bailey, you wanted to mention consent decrees / settlement agreements include end-user testing

kirkwood: might get into tracking technology, W3C would have to track, really complex, a binary approach is needed

<alastairc> user testing or AT testing?

<Zakim> hdv, you wanted to respond re regulator

Bruce_bailey: work for 508 never required testing, litigation frequently includes user testing, bigger problem end user testing gets substituted to developing to the code, this is the more difficult issue I think

who is speaking?

<Zakim> alastairc, you wanted to comment on tracking technology, and cleaner approach

<kirkwood> definitely take your point Chuck I wasn’t the user testing, pointing to specific technologies? if not that’s ok

Hidde: it's much more complicated, WCAG3 is challenging, binary nature helps, harder with this proposal

<bruce_bailey> +1 to Alastair about making it transparent that a11y is hard -- but not making a11y harder

<kirkwood> would technology need to be tracked, or no?

<Zakim> Chuck, you wanted to thank Hidde for participating

alastairc: harder or more tranparent that it is hard? we make a lot of assumptions with WCAG2, different regions have differeent AT, makeing it more tranparent it's tricky, I don't think it's more complicated, more work for us, need to think about other regions of the world

<Rachael> +1 to asking ourselves the question of what adds complexity and what makes exisiting complexity transparent

chuck: thank you for scribing, happy toh ave you aboard, continueing on exception itself, people have expressed support for the exception, lot of support for exception, concerns how it would work

<bruce_bailey> Noting that U.S. Section 508 does not require end-user testing. Trusted Tester and ICT Baseline for Web also do not include end-user testing.

hidde: regarding Alastair point, complexity is real, it helps our a11y mission, lot more organizations reporting on their a11y, adding more complexity might be harder for them

<bruce_bailey> https://ictbaseline.access-board.gov

kirkwood: very concerned on definition without tech speak

chuck: alastair, thoughts? remvoe exception but note it as requiring more explanation

<kirkwood> effectively defining the exception may be a problem no? ‘drive a truck through it problem’ ?

Nay: lost on exception if tool has a bug, they can claim it as an exception

alastair: exception not aiming for bronze international company, an example a component doesn't support it, html doesn't support, you'll using HTML, you know bug exists, compnent doesn't support it, add note to ACR that there is a known bug,

nayan: not going to admit it publicly,

<Chuck> scribe+ Chuck

nayan: two year is a stretch, ADA does not require waht you provide, make it broader, show tried to make it work, might be 8-10 versions of the software

graham: on exceptions an AT doesn't support implicit labels, I can claim I still match Silver, feels ike a never ending, this one doesn't that doesn't, where is the line, 2 out of 7

alastair: we have published a method that has generally been accepted

graham: would have to pass every single AT that we list?

alastair: need some boundaries, AT doesn't support the guideline, now shows a web page, there is a list of AT, you can use a method even if not support by that tech on your list

<Chuck> ljoakley: Want to make sure that we are aware that all these technologies, you need to have an accessibility report avail to the report.

<Chuck> ljoakley: If an AT doesn't support labels, there should be a report that states that. We don't have to have a report that lists everything from everybody.

<Chuck> ljoakley: If they don't have one they will run into court.

<Nayan> is this for the government entity?

<Zakim> alastairc, you wanted to comment on vendor lead times

<Zakim> Chuck, you wanted to say examples

alastair: you can get al ot of versions of things quite quickly whether an AT, in terms of taking on nw features not quick, example new version of aria, not quick to uptake new components in AT

chuck: be careful listing technologies, let's use hypothetical, prefer use jedi voice assistant

dan_bjorge: at in OS can you make a claim that it's not supported but old version does support

<Graham> So we cannot mention a specific technology not supporting something, but we are going to suggest that people add specific exceptions when technologies do not support something? If we can't say it here then how can we expect others to say it? 🤷🏼‍♂️🤣

jtoles: are we going to have a mechanism to outline, have to be mentioned in ACR? technique doesn't work with a specific tech, okay as long as it;s in the ACR. ask what are common techniques that we might not know of, are there exceptions that we should be aware of

<Zakim> alastairc, you wanted to comment on an incentive thing

alastair: not sure I understood the last question, graham's point "don't list specific" tech, could setup incentive to publish a11y exceptions, that's a public bug report, a useful incentive

<Graham> Ok got it, I was just confused that we are suggesting publishing support stuff and then weren't discussing it, get you now!

<kirkwood> maybe you could just set up a secret list ;)

Chuck: in q, to absolutley confirm graham's point, I am cautious about mentioning specific tech, should be motivation to fix, don't want to impune but published exceptions, how to be factual and not impune

<Zakim> alastairc, you wanted to comment on john's question

<mbgower> I've mentioned this before but there is work going on in this space, such as https://aria-at.w3.org/

alastair: on John's question mentioning John's comments, we need to pin down the number of things, an AT with bug for more than 2 years, want to make the point we've pubioshed it, believe that it works across the board, adding transparency

<alastairc> scribe+

<Chuck> ljoakley: Going back to what Chuck said about not mentioning a specific technology, if they have already published something is a bug, then we can use that.

<alastairc> scribe-

<Chuck> ljoakley: "Makes perfect sense why we have in silver". All these browsers have an ACR and a bug list somewhere. Using real life examples can help clarify maybe one of the guidelines.

<kirkwood> +1 to Lori

<Chuck> ljoakley: I think its helpful to use a current product's ACR in our group to say "here's an example".

<Zakim> alastairc, you wanted to comment on next steps

mbgower: added a link for aria, trying to work on automation AT standard, we're not the one working on this

<Graham> I want to be clear, I didn't pick on DNS randomly, it is a documented problem on a11ysupport - https://a11ysupport.io/tech/html/label_element

alastair: any further thoughts, please post as bruce has, write this up as a PR, we an review from there, any concerns let us know

chcuck: anything additonal frome thchairs?

<Detlev> presennt+

chuck: motion to adjourn

<Ben_Tillyer> Thanks all

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)

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