Meeting minutes
<Lisa> I love Rachaels hat
<Jennie_Delisi> +1 - great hat!
Content maturity and publication approach
Rachael: Talks through slides. https://
<PaulG> I think the % approach leaves too much "wiggle room" for entities to not fulfill their responsibility while staying in compliance with laws and regulations.
PaulG - it depends what goes into baseline. If baseline is similar to WCAG 2 AA, then the % becomes a way to score more than baseline. If the baseline is slightly less, it depends what % you define.
<Fazio> using the term maturity levels in your process can be problematic as it may be construed as maturity model applicable somehow
Open to other terms, but "maturity" as a term is much wider than models
<PaulG> "status" could work
<hdv> +1 to Fazio's point
<kevin> -1
<Ben_Tillyer|2> -1 to David's point
<bruce_bailey> https://
The use of "mature" content is very common, including in W3C
<Fazio> I honestly foresee confusion down the road
<bruce_bailey> +1 to Janina that "mature" or "maturity" cannot be reserved term for use only in context of AMM
<Zakim> kevin, you wanted to talk about database
<BrianE> Could someone post the link to the slides again? I missed it the first time around
<Ben_Tillyer|2> https://
<bruce_bailey> https://
<kirkwood> +1 to Janina
<bruce_bailey> +1 to Janina points
<Lionel_Wolberger> +1 from me too
https://
<hdv> thanks!
This content is automatically generated from this PR: w3c/
<bruce_bailey> For the Focus Visible Decision Tree specfically: https://
<Fazio> sheri is talking psychological flow
<Fazio> +1
<Zakim> alastairc, you wanted to comment on how/whether conformance is part of WCAG vs elsewhere.
<kirkwood> “regulators” will always choose the middle
Hmm, that does argue for more levels then
<Ben_Tillyer|2> +1 my understanding too
<hdv> re choosing middle: didn't regulators also choose AA, because AAA is sometimes impossible to completely meet all criteria at the same itme?
<Jon_avila> Where is the conformance model with the challenge of something minor failing the baseline?
<kirkwood> regulations will say you “need it to be accessible to x community” if it’s “not an undue burden” to the business
<Jon_avila> I agree pre req isn't really a level.
<kenneth> +1 I suspected "level" might've been causing some of the confusion that came up earlier in the week
<kevin> +1 to Rain's point on worrying about what regulators might do
<Zakim> Rachael, you wanted to answer number of levels
<kirkwood> +1
<bruce_bailey> @kirkwood regulators always picking the middle is not correct in my experience
<kirkwood> +1 to Rain
<Jon_avila> I worry that if we have too many levels people will become complacent with only meeting a minimum level - unless regulators choose a high level.
<Zakim> alastairc, you wanted to comment on having to round-robin between content and conformance / structure
<kirkwood> Think we should keep in mind It worked before. Very well in my opinion. Changing it will be a risk. We should think if its worth it.
<Sheri_B-H> Sheri discussed that we need a good definition of harm. Everyone agrees flashing causes harm, but what about timeouts, keyboard traps, and financial harm?
Sheri_B-H - We do have a strawman proposal, look through the outcomes sheet. https://
<Ben_Tillyer|2> +1 to Makoto
<Zakim> Rachael, you wanted to answer the % question
<Jon_avila> In addition, we would not want folks to not do some of the baseline and do enhanced to get a certain score but not meet the baseline.
<Zakim> alastairc, you wanted to talk about applicability across sectors etc
<Ben_Tillyer|2> Session has 32 minutes left according to the schedule
<kevin> Correct
<Zakim> Rachael, you wanted to go back to coordinating
<kirkwood> woo hoo!
<CharlesL> Here is a link to Benetech's Global Certification program to help publishers create fully compliant EPUBs. https://
<Rachael> proposal on coordination: 1. Publish 2. Meet and review publication and key question 3. 1 month to give us feedback
<kirkwood> +1
<Chuck> note: APA chairs agree with the proposal, and will review on the 9th.
<kirkwood> financial harm
<Zakim> alastairc, you wanted to comment on levels and percentages
<Zakim> Rachael, you wanted to say levels could be based on % divided by functional needs
<Ben_Tillyer|2> +1 to Rachael
<Sheri_B-H> Sheri discussed that not everyone's 70 % would be the same, and the need for a recommendation of how companies report their levels and what amount of detail would be required
<kevin> Sheri, I worry that that is leaning into the regulator activity a bit too much
matatk - there is a list of decisions we try to keep: https://
<Zakim> alastairc, you wanted to ask whether it's a good idea to give people the mechanisms to separate by group
<kirkwood> +1 to Alastair
<Zakim> Jennie_Delisi, you wanted to discuss considering performance evaluations
<Zakim> Rachael, you wanted to point to links and explainer
Jennie_Delisi - did you mean that the employer is testing the potential employee on their knowledge of WCAG?
<Jennie_Delisi> alastairc - employers evaluate sometimes on a hired employee's ability to produce accessible content so it meets WCAG.
ah, thanks
<Jennie_Delisi> alastairc - they could also be hired to evaluate based on WCAG or code or design web or apps/software
<julierawe> Can you please turn off the autozoom on the main camera?
Slideset: https://
<Zakim> alastairc, you wanted to suggest default method of engagement
<Zakim> alastairc, you wanted to comment on the breadth of scope
https://
<Zakim> Rachael, you wanted to ask about marking options likely to need internationalization
<Ben_Tillyer|2> @kevin https://
<r12a> https://
<Zakim> alastairc, you wanted to suggest the "Layout" and "Text and wording" sections are probably good places to start in https://
<Rachael> checklist is a link away at https://
<r12a> https://
<Chuck> +1
<Chuck> +1
<alastairc> +1, suggest initial review at 'developing' stage for each guideline.
<xfq> +1
<kirkwood> +1
<kevin> +1 for try and iterate
I think the first try could be with the next publication, we have 2 guidelines moving to 'developing'
<Jan> This is the process the community group is following to provide initial feedback on WCAG 3 outcomes: https://
<Chuck> +1 alastair
<Rachael> Proposal: 1. CG and Internationalization WG review outcomes and let AG know which items are likely to need internationalization input 2. AG will send guidelines over when they reach developing for review and feedback 3. We will check in after we get feedback to see if this process is working
<Jan> https://
<Zakim> Chuck, you wanted to share that the link is not shared
<xfq> https://
<xfq> Mastodon account ^
<shawn7> my comment was too specific :-)
<shawn7> +1 to Makoto
<Rachael> Proposal: 1. CG and Internationalization WG review outcomes and let AG know which items are likely to need internationalization input 2. AG will send guidelines over when they reach developing for review and feedback 3. We will check in after we get feedback to see if this process is working
<Jan> The next community group meeting is on October 9, 2024 at 9:00 EST
+ AG will incorporate the i18n checklist into our process.
<Rachael> Proposal: 1. CG and Internationalization WG review outcomes and let AG know which items are likely to need internationalization input 2. AG will incorporate checklist into the working documents 3. AG will send guidelines over when they reach developing for review and feedback 4. We will check in after we get feedback to see if this process is working
<kirkwood> link to long checklist?
the short checklist, https://
<Zakim> shawn, you wanted to say 200 sentences not necessarily understandable. CG instead of I18N
<Rachael> Proposal: 1. AG will incorporate checklist into the working documents 2. AG will send guidelines over when they reach developing for review and feedback 3. We will check in after we get feedback to see if this process is working
<julierawe> Kirkwood: There is no long checklist. The short checklist has links to many longer checklists.
<xfq> +1
<Rachael> 0
<kirkwood> so the CG is doing good work!
<Rachael> Proposal: 1. CG is conducting an early review of checklist for what needs internationalization review. 2. AG will incorporate checklist into the working documents 3. AG will send guidelines over when they reach developing for review and feedback 4. We will check in after we get feedback to see if this process is working
<julierawe> Rachael can we avoid using "checklist" in more than one way?
<Rachael> Proposal: 1. CG is conducting an early review of list of outcomes for what needs internationalization review. 2. AG will incorporate checklist into the working documents 3. AG will send guidelines over when they reach developing for review and feedback 4. We will check in after we get feedback to see if this process is working
<xfq> the long checklist is https://
<julierawe> Thank you
AGWG Joint Meeting w/ ARIA WG
Meeting page: https://
ARIA & AG Joint meeting
Chuck: thanks everyone for joining
alastair also joins us to present
i’ll moderate
it’s not our intent to scribe
but some people have volunteered
are there members that might want to view this later on?
Chuck: i’m gonna review the agenda
consider if there’s something you want to add
we can discuss it
<Zakim> ZoeBijl, you wanted to ask about using the APG more
ZoeBijl: Matt King has asked me to ask the group if there’s a way we can use the apg more in this work
[introductions happening]
<MJ> Could we get captions on the Zoom call?
alastairc: where are we now with wcag 3?
we are establishing a reasonable publishing cadence of every six months
our goals of this charter are to work on the structure
we should have enough to say our structure is good for them
we should have a good conformance model
we should have a good plan for delivering the rest
we’ve fairly settled on the structure now
guidelines are the plain language explenation
the outcomes are similar to the success criteria
assertions
it’s that kind of statement that tells authors that ??
it’s things that are not ?? testable
but more towards the organisational ??
so as i said each outcome is somewhat similar to scs
bit more granular
prerequisit was supposed to be a small subset
Safety Issues, needed for AT to work, likely to prevent task completion even with ideal current AT support.
baseline was supposed to be more than prerequisite
Author provided methods that aren’t currently met by AT, applicable to all sites and products.
enhanced is things above that baseline
Can be met in other ways, or may be domain specific.
bit like triple a
you can meet baseline and there should be more incentive to meet the enhanced guidelines
how does that translate to the conformance models
we’ve had discussions about this
it was fairly clear
everyone had expectations
we might merge the prerequisite and baseline
baseline is sort of a minimum as the name implies
we might want to use more percentage levels
so it could be baseline + percentage of enhanced
there are very ways of getting that ??
you could get people gamifying it
going for easy ones for example
there’s still discussion on that because of that
as we go through publishing
and get review as early as possible
“oh yea, wcag 3, we’re gonna test for that now!”
that’s not the way to go at the moment
that’s for the sections with placeholder status labels
Maturity levels for the document:
Placeholder - AG has identified we need content but do not yet know what it should look like
Exploratory - AG is exploring one or more possible directions for this content
Developing - AG has high confidence in the direction and some confidence in the details
Refining - AG has high confidence in the direction and moderate confidence in the details
Mature - Content is believed to be ready to become a W3C Recommendation
for review we’ll announce what are the new bits
Chuck: let’s pause for comments
jamesn: you were describing the pre-tpac levels
it sounds like you’ve had quite large changes
alastairc: it’ll be difficult to summary
we discussed a lot of different solutions
soemthing like functional categories
i don’t think it’s going to be a million miles away
from the pass/fail
you’re mostly are going to have outcomes
and some will have the enhanced level
at the moment we have a 183 outcomes
<Zakim> jamesn, you wanted to ask how the TPAC discussions might impact the conformance levels
at the moment we try to grapple with as many as we can
which are more specific
which should be assertions
etc
jamesn: so, complicated?
alastairc: ha, yes
cyns: can things move from one level to another?
like the auto captions on this zoom call are pretty good
but they used to be bad
alastairc: yea
so we try to write things so that they can be fulfilled by either author or user agent
the prerequisite we ahev ??
at the baseline we have the focus indicator overwitten by the author, that’s an author responsibility
but if ?? improves it’ll be an author responsibility
cyns: is there a process for documenting these changes?
alastairc: yea we have an accessibility reported section
if you’re going for a high level of conformance there might a requirement for at testing
Rain: this is an intersting thing to investigate
i wonder if it means we also want to include things that specificy how we include backward compatibility
if we’re sayingt this needs to be fulfilled
but it’s up to the author to decide if it’s fulfilled by the author or the user agent
so how far back do we ask people to support
<alastairc> More on accessibility supported: w3c/
alastairc: that comes into that accessibility reported section
it’s a tricky thing
<cyns> I have suggestions for that discussion, which may be outside the scope of this meeting
but what were getting to as a group is a baseline level of conformance
you should be able to rely on the specs or the techniques provided by w3c
but if you’re a governmental agency you might want to go a bit further
we’re trying to build a model that builds up
once you get more advanced you’ll get more responsibility for testing
Chuck: we’ve been discussing the conformance level
Chuck: We reviewed maturity levels earlier in this session
alastairc: i think that’s a quick overview of what we had last year
as a user i should be able to understand non-text content (alt text)
when taking this more user needs approach first
<cyns> kevin I'll comment on the issue
what we think we’ll find is gaps
we know what it’s like on the aria side
if you know of a gap
and there’s a new feature of some kind
what’s been your process etc
how much do browsers and at vendors get involved?
how we approach it now is that there may be a user need?
we might be writing an author requirement
but can we feed that through to “here’s a gap” and ??
if there’s no support, how do we handle that
<Zakim> spectranaut_, you wanted to answer that question if I understand it correctly
spectranaut_: if i understand the question correctly
one question i heard
was how does the aria wg handle new technologies
alastairc: yes
spectranaut_: we have a lot of representatives from different technologies
like at and browser vendors
but also authors
so we figure out how those things align
and how we can support all of them
and that’s difficult
a lot of it comes down to personal relationships and offline conversations
jcraig: it was your process change that i appreciated
???
spectranaut_: ah yea, we try to be a little bit more strict with tracking these new technologies, having tests, etc
tests that can cover both new aria and at features
there was also a new question of how you can work more with us?
alastairc: yes
is there a mechanism for us to feed these things through?
like if we discover a gap
what’s the next step?
jamesn: what do you mean with feature request?
alastairc: if one of the guidelines was able to remove ?? content
that required some content or markup
jamesn: most things like that, we should say it should be a html feature, not an aria feature
we said this year that we want to finish in-progress features. all other work should be in support of html features
and also a big focus on tests
unless there’s commitment from at and browsers vendors
<Zakim> jcraig, you wanted to mention the new ARIA features don't make it in w/o vendor support, not even to an Editor's draft
jcraig: one addition to that
there used to be that spec editors
early on in html
that authored things in a vacume in a way
there’s been a major shift
to implement what’s specced
aria has made a change due to val’s chairing
that aligns with that
so new features proposed
don’t land in the editors draft
it stays in the pr
it stays in the process
that’s a big change
it’s not just like get two implementations at the end
it doesn’t make it into the draft unless we have implementations and tests etc
cyns: if you have featrures ??? how
????
for html or a wrapper
jamesn: we’re happy to receive the request
but we probbaly wouldn’t do it
alastairc: i was gonna say
yes, to james’ last point
happy to hear
and to jcraig’s point
to how things used to be
<cyns> s/???? we can connect you with the people from browsers, at vendors, html, css etc.
yea, we wouldn’t write anything into wcag3
maybe we have tested reader mode
and that works well for this case
it’s that more objective testing model?
we might put something in the baseline model
spectranaut_: you can always email the wg
or the chairs
but we just facilitate the meetings
so probably making an issue on ARIA and we will schedule a discussion for the working group after that
or come and discuss it during a meeting
<aardrian> +1
would be intersted to hear what you need from us to ???
<Zakim> jcraig, you wanted to add on about prioritization of those new features....
jcraig: to add onto that
about newer implementation requirements
it doesn’t benefit the web platform as a whole
so there’s loads and loads of good ideas
but if one implementation makes up something new and it doesn’t work for half the web
just because someone has a good idea, if it doesn’t get done immediately, doesn’t mean it’s a bad idea
but in order for it to reach a threshold you need to have at least three to keep them in sync
[something about web sync?]
same type of thing happens all the time
alastairc: yea and we’re sorta passing requirements down to web authors as well
accessibility reported link posted earlier
there might be places where the main at used don’}t have good aria support
or don’t meet new assumptions we’ve had
<kevin> w3c/
that’s why we’re almost going for a lowest denominator approach
<Chuck> More on accessibility supported: w3c/
but put more testing responsibility with the author(?)
we’re not trying to invent things but it might be that we’re putting author requirements that might be better as user agent requirements?
AGWG Next Steps
??
there are some which are built up cummilatively
if you have a conformance statement
AGWG Next Steps
in general we’ll be able to highlight some
if we think there’s something specific you might want to look at
but we’ll be updating things with that maturity levels
six months ago we published a big list of outcomes
???
that was the main question last time
we will be doing some town hall style kinda sessions
outside of agwg, outside of the w3c
is there something you would like to do in terms of other kind of engagements?
[some heads shaking]
so basically gitgub is fine?
<ljoakley> q_+
spectranaut_: nothing is left on read in the aria repo
[laughter]
lori: what friends say about github, it’s not friendly to people with disabilities
alastairc: it depends which way conversation you’re talking about
when we were doing wcag3 discussions
we do different kinds of outreach
this conversationwas more about the two groups
spectranaut_: we do have people with disabilities in our group
people that use at
we also have representatives of github
<Zakim> jcraig, you wanted to ask about Lori's GitHub accessibility question
so good place to report bugs
jcraig: i was going to say the same thing
we have a good mix of people doing code reviews
not saying there are no issues with github
but it’s better than anything we’ve used before
and like Val said we have people actively looking at how to improve github in these areas
when i hear people say gh isn’t accessible i challenge them to tell me how it isn’t
there’s some ui patterns that need to be learned
some of it is genuine bugs though that need to be fixed
so there’s a mix between learning new patterns and issues
and like we said there’s github people that want to fix these things in our group
<ljoakley> ZoeBijl, thank you
Chuck: one point is that the accessibility of github is not relevant to this meeting
second is that, and Rain may address this, one of the challenges with github is the cognative load
it can be a complex tool
Rain: yes, thank you
completely udnerstand why communications through github are helpful
unless we found at the cognative tf that github is cognatively inaccessible
finding it hard to find what to look at
being overhwelmed by the number of inputs
or people with limiting working memory finding it had to use
we’ve worked with agwg through a long process to figure out how we can communicate
it’s important that these communication hosts to allow these flows
it has to be a bit of a seperate club
we can certainly find a way to make that not overhelming
but having those…
i’m a spreadsheet person
<spectranaut_> spectranaut_: thanks for the information, we can work that out for each particularly discussion topic between the two groups
Rain: we need to recognise for those people we try to include with cognative disabilities
<Zakim> jamesn, you wanted to add that we also accept feedback by email on the aria spec
there’s no perfect solutions
jamesn: i recognise that github can be difficult
for our specs we also allow for emails
we do have a mailinglist
github issues are more trackable
we suggest that github is the tool to use if you need to communivate with us
<Zakim> alastairc, you wanted to comment on other github things and to say that the solutions tend to be how it is used, rather than the tool itself.
but we can use different tools if and when it’s needed
alastairc: yea i want to say that it’s not generally the technical interface usability
which is to say that we stuffed everything into github
having it in one place is helpful
but we should make effective use of discussions
going between places also has its downsides
having to keep track of multiple places
<Zakim> cyns, you wanted to say we also have video call discussions of issues as needed
cyns: we use issues to start discussions
if we had weekly calls
or separate meetings
the discussion doesn’t have to happen in github
but we use it to track the discussion
jamesn: github is more of a tracking thing for some issues more than others
Rain: from coga, to collabortate effectively
if we had a mechanism to regularly check in with eachother
<Zakim> jcraig, you wanted to mention one way an ETSI group uses a GitLab [sic] workflow to auto-file issues... We could probably leverage the GitHub employees in the group to find some form of solution that works for COGA/AGWG members to at least file issues, and not be overlooked.
i think we can have a succesful communication path
jcraig: there’s another group that i’m involved in
i acknoledge that any interface can be challenging
i find the volume of email more cognatively challenging that github
there’s a range of things
hopefully the reasonable accessibility of github didn’t come across as dismissive
this is a real issue
[some discussion about the european accessibility guidelines]
???
we can come up with some path that works for both of us
perhaps there are ways that we didn’t were possible
alastairc: our goal was to give an overview of wcag3
i think we’ve done that
thanks everyone! good show