Meeting minutes
Jaunita_Flessas: I was going to change affiliation, but Navy Federal is going to let me keep the affiliation eventhough I changed employer
DJ: I have a change of affiliation, I am independent now
alastairc: any announcements?
Chuck: we are planning to present on intersectional disabilities in one of these calls, sometime end of July
Chuck: to talk about what it means to have intersectional disabilities… I am looking for volunteers and have received one that I am aware of
WCAG 3 details requirements https://github.com/w3c/wcag3/discussions/306
alastairc: this needed a little bit of a restart
alastairc: to ensure everyone's aware of what we're aiming for
[alastair presents]
alastairc: we want to look at this to find out how concrete they should be
alastairc: this is related to criteria for success criteria
alastairc: bullet points for things each criterion should do
alastairc: for each item on the roadmap we want to know by which date it could be defined and when we'd expect examples to be included
alastairc: so we'd like to break down the overall goals into smaller things
alastairc: and attach milestones
alastairc: digging into the topics… short names was one of the ones we had mixed support for
alastairc: some people suggested we should keep the numbers, in that case we'd need to work out how numbering would work
alastairc: there was also some pushback re path for new requirements and whether everything should go through it
GreggVan: re the numbering… the problem you're trying to solve by removing the numbering is that we're trying to add things at the end which can make the order weird
GreggVan: if we have things like assertions, that we give an extra thing like A or S… if you don't want them to get mixed, you can avoid that
alastairc: yes we were trying to solve problem of WCAG 2, where we'd have to renumber chunks of the content, or we add them to the end but then order doesn't make sense
alastairc: gregg's suggestion might help for some things
alastairc: but if something moved to foundational at a later stage, might still cause a problem
Rachael: some got really great discussions
Rachael: there are a couple of ways we can go through this… give a summary of where different ones are… we'll probably have to talk through some, especially ones without support. Some others are about wording
Wilco: I find all of these are fairly vague, I'd like to see us make them more specific and dive more deeply into each of them by themselves
Wilco: we should try and find out what we mean by all of these, what are the acceptable solutions and possible alternatives
Ben_Tillyer: wouldn't want to repeat the numbering format of WCAG 2.x
Ben_Tillyer: having the ability for W3C to provide the facility to build with tags would be amazing
Ben_Tillyer: apart from in audits, I rarely hear people say the number
kevin: a couple of points… with W3C hat off, I like numbers
kevin: re the mentioned focus related SCs, we might not get stability in any of these, clarity more important and this provides clarity
kevin: the WCAG related tools are outside TR space and they are used extensively, we can think about how tagging is used in tooling
<Zakim> Rachael, you wanted to respond to Wilco
Rachael: the conversation split into two, that's a little hard to follow… first, from Wilco, are these the right reqs and is this the right path forward… and then second, the numbering
Rachael: re the first point… we've had these discussions for a while in different venues, this is attempting to capture it at a high level
<bbailey> QuickRef that Kevin mentioned: https://
Rachael: and then from there document down
Rachael: very few of these requirements are new or issues group has not talked about recently
hdv: The numbering one... I work as a developer of code in WCAG EM Report Tool and QuickRef. Shadi and Wilco have also done. It would be hard to build that without stability in numbers. I can only imagine building tools that build on WCAG. It would be hard to not have the numbers. Short names stable would be good, but still hard to reference without numbers.
hdv: If we want accessibility to increase, we should make it easier to build tooling.
shadi: regarding the criteria we're defining, many felt very broad, some very specific, like the numbering one
shadi: if we were to achieve each of these, where would be ? what would the outcome be?
shadi: it's not clear to me what the result would be
shadi: my suggestion would be to firm up and try to define in a charter, for a period, state what the outcomes would be
<Wilco> +100
shadi: maybe it is clear to others, it wasn't clear to me
GreggVan: thanks for doing this early, that avoids chaos
GreggVan: the numbers are important, not for referring to, but after you refer to something
GreggVan: numbers are essential for finding criteria, ass the alternative is having them alphabetical, that would be really hard to look through
<Ben_Tillyer> Everyone writes reports in different formats, I've seen many reports that don't use WCAG 2.x "in order" numerically
<Zakim> alastairc, you wanted to ask if people would be ok with renumbering everything in new versions...
alastairc: what we can't do today in the requirements is predict
<jspellman> w?
alastairc: some of these aren't going to be concrete yet, for where we are don't think that's a problem
alastairc: closest we had in WCAG 2 is the acceptance requirements for SCs
alastairc: that's something that was a living document
<Ben_Tillyer> +1 to non-chair alastairc
alastairc: re numbering, chair hat off… I agree each requirement should have a number, but do we focus on it?
alastairc: two ways this could work: either renumber things, or reorder things, regardless of the number
alastairc: don't know if we can change things in another way
jspellman: I would like to remind people, as the person who seems to be the living historian of this project work… the idea of not using numbering came out of UX research done in 2017, on how to improve WCAG 2
jspellman: the reason was the numbering made a barrier
jspellman: that made it seem like WCAG success criteria were not accessible to them, you had to memorise and refer to things by the numbers
jspellman: it was about the usability of WCAG 3
jspellman: it came from the user research department of Bentley University, an outside professor, who did a large survey
shadi: to confirm I understood you correctly, alastair… we previously said the reqs doc is kind of locked and we're only discussing SMART, did I understand correctly there is possibly to look at reqs themselves?
shadi: if something comes up we could add it?
alastairc: yes this was our first pass at creating general requirements doc
<jspellman> Bentley University
shadi: so we could update reqs separately?
GreggVan: the problem is that people refer to the number only, not the name
GreggVan: it's like talking in code and we should remind ourselves
GreggVan: wanted to say it's also fine to leave questions under items
GreggVan: that sometimes advances as much as adding an answer
<Zakim> kevin, you wanted to ask when renumbering matters
kevin: thanks Jeanne for the reminder re research. Two questions: when does renumbering matter? In the point we're at stable TR referenced by policy, we can't renumber things in that, but renumber subsequent versions may be something that happens.
kevin: problem in certain audiences, not others
<kirkwood> +1
<kirkwood> findablity tool too
kevin: providing options would be useful, with/without nrs
<Zakim> hdv, you wanted to respond to ux research
hdv: I think they are 2 sides to the same coin. Some will refer to numbers, some to names.
hdv: It can be confusing to some if just numbers are used. Where I work, we use numbers a lot. But when talking to the public, we usually use names.
hdv: Makes sense to leave out if that's what the research supports.
<Ben_Tillyer> My thought is that the 2.x numbering is used as the unique identifier AND as a way of determining what part of the spec they are in and their relationship to each other.
Rachael: chair hat off, if we use the short names, they wouldn't be sequential under the guidelines but we'd have the suggestion
<Ben_Tillyer> ...and that's an issue
<DJ> rachael++
Rachael: associating number with a requirement as a separate set of information could work
<Zakim> Rachael, you wanted to suggest numbering approach
JenStrickland: how we refer to the SCs, with numbers or names, we want to keep in mind, once we have clear vision we could be more specific… if we look at how the subgroups have broken down… not sure if we want to continue to involve WCAG 2 numbering? maybe I was wrong?
JenStrickland: as someone bridging that gap between development and design, my experience aligns a lot with what Jeanne talked about
JenStrickland: but what Hidde said resonates, re accessibility folks that know the number well, and that others will use the names. As standards folks we should focus on all of our users
<Ben_Tillyer> +1 to Jen
JenStrickland: or it'd be done by 'WCAG in plain language'/Wuhcag etc kind of pages
alastairc: it would be great as folks look at the GH discussion, add their thumbs up / down, ask questions, add comments, etc. That way we can make some progress, so that we know what we can/should achieve and when
<kirkwood> agree to both
two possible ways to think about a schedule
Rachael: this is a big draft
Rachael: and though we need more data, we want to start the conversation.
Rachael: one possibility is to get as much done at the same time, in stages
Rachael: prioritising foundational and normative content
Rachael: if we take this option, first stage would be just foundational reqs (eg not informative content), probably around 100 requirements
Rachael: that way we would have method, testing info, requirements… but not the informative supporting documents. Just the requirements for it
Rachael: we would also have the conformance model, and informative note, advisory, not normative, on how we think it can be used in legislation
Rachael: that would take 2 years… then in phase 2, we'd do assertions
Rachael: then phase 3, we would add supplemental requirements and minimal reqs… then in phase 4 we'd do informative docs, then in phase 5 add research based best practices
Rachael: then option 2… we would focus on everything that is comparable to WCAG AAA, more opportunity for public feedback …3 phases instead of 5, and ends in 2031
<JenStrickland> Adding to the minutes what I intended when I spoke: was proposing that once we have guidelines more developed, we would identify a taxonomy for them (i.e., structure-headings, contrast-color, etc.) and continue the numbers through from WCAG 2.x to support regulations, testing, etc. This would provide designers, developers, product, etc., a "plain
<JenStrickland> language" reference to the guidelines. We could review all the guidelines we have now to develop that taxonomy. the Sustainable Web Group has a similar pattern for the Web Sustainability Guidelines.
[struggled to type along, see slidedeck for gaps in minutes]
Rachael: *reads out slide 3, comparison table
Rachael: both have pros and cons. From option 1, we have a larger chunk of things that are done, but more risk. From option 2, we get a whole package out sooner, and more opportunity to get feedback, but it is a smaller amount of things, but a bigger risk that people pick up WCAG 3 but not go beyond WCAG 2
Rachael: it does allow us to refine normative wording with informative docs
Wilco: I wanted to ask what we mean by mature?
Rachael: that refers to our maturity model
Wilco: at what point would that get us to Recommendation?
Rachael: ideally if mature it would not change and be ready for Rec
Rachael: in option 1, we'd get to Rec with larger amount of content. In option 2 we'd get to Rec with smaller amount of content
<Zakim> kenneth, you wanted to clarify informative documentation in table
kenneth: would it be comparable to WCAG 2 AAA?
<Zakim> Chuck, you wanted to share my opinion
<kenneth> RE "what is Mature": https://
Chuck: [chair hat irrelevant] I prefer option 2, I recall when we put out content for WCAG 2.1, it didn't have fully flushed out content it caused great challenges, and caused the world some great challenges
<kirkwood> Feedback: If the highest priority is early, broad applicability and leveraging community feedback for refinement, Option 2 seems more advantageous despite the risks of releasing "refining" content. If the priority is to ensure the foundational elements are as perfect as possible before broader release, and the community can tolerate a longer wait, then Option 1 might be preferred. However, the explicit mention of users not being able to "really [CUT]
<kirkwood> 3 until 2030" for Option 1 is a significant practical drawback in a rapidly evolving digital world.
Chuck: we would have been better off with more supporting documents
Chuck: so I am more in favour of option 2
JenStrickland: looking at slide 4, the comparison… at what point in each one of these would public input come in?
Rachael: we're aiming to publish and get feedback every 6 months… we tried to keep that pace and want to continue to keep that
<Chuck> +1 keeping pace and encouraging public feedback
JenStrickland: are there any other world pressures that might be useful to consider as we look at these options? was doing the math… thinking of US administrations… for a 2024-2028, the backlog of section 508, option 2 does make sense
JenStrickland: would be good to know how we codesign our guidelines with the users, whether they are regulatory, a11y folks, designers, developers… where are those opportunities? how do we make sure doing with them?
GreggVan: +1 to chuck's comment, if we go out early and only have what we had in WCAG 2, there'll be huge pushback
GreggVan: we're better off, even if it delays things, to have solid foundations
GreggVan: it's going to be a massive effort to get adoption, we must make sure it is good
<kirkwood> A quick SWAT analysis with some AI assistance: Option 1 is a more conservative, methodical approach. Its strength lies in building a potentially very solid foundation, but it risks losing momentum and relevance due to the long wait for a usable product.
<kirkwood> Option 2 is a more agile, user-centric approach. Its strength is getting a comprehensive set of guidelines out for use and feedback much sooner, allowing for real-world driven refinement. However, it risks initial imperfections and the challenge of managing iterative development effectively.
Wilco: I'd love for these to be specified more specifically. I'm interpreting differently than others. I'm reading that in 2029 we'll have the same coverage. I'm not seeing anything on improvements.
Wilco: There may be assertions. Same concepts, nothing new for next 4 years. Am I reading that right?
<alastairc> JenStrickland - irrelvent to the question of option 1 or 2.
<alastairc> we'd aim for that anyway.
Rachael: It would not be a lot of new work. new conformance model yes. There would be a different prioritization. Does it have the width and breadth of work we have done? No, that would be option 1.
shadi: From my perspective, if we have more or less same content as WCAG 2, but in a substantially improved conformance model that matches reality, that may be good progress by itself. We don't have to add more.
Shadi: I agree with Gregg on conundrum, if we publish w/o this we have one issue, if we publish w/o that it's another issue. But how to get from A to B, maybe that's the requirements doc. But needs to be more thorough.
<shadi> +1 to mbgower
<mbgower> is there a way to have a wcag 2.x specific target: a non-backward compatible version which attempts to fix the obvious shortcomings without adding any NEW requirements?
<mbgower> (any new SCs, I guess I should say)
<Wilco> +1 Mike
Rachael: The purpose of bringing this to the group is to start thinking about it. We've had varying conversations, lots of different approaches. These are two. They prioritize different things. If there are other options, please let us know what those options are. We will add to this deck.
<shadi> +1 to mbgower (though, non-backward compatible might make it a WCAG 3 -- not the one we currently mean but a 3.0)
Rachael: We don't have enough data to make a decision, but we wanted to get everyone thinking on this. We need to finalize specifics on the plan to move it forward. The requirements are not enough yet, but we have to start somewhere.
<GreggVan> if it was unclear -- re option 1 and 2 I was saying we needed to have a fully developed document to cause everyone to move to this whole new model. Covers the old, adds the new and has support docs
Rachael: We will come back to this conversation, but we wanted to get everyone thinking on this.
<shadi> thanks Chairs for these discussions!
<mbgower> +1 to thanks for these discussions.
<bbailey> kirkwood the AI view of which option gets something useable first, seems reversed to me
<Jaunita_Flessas> Need to drop early
<Jon_avila> I think we have 3 options 1) WCAG 2.2 in new format 2) Only criteria new from 2.2 3) both
<Ben_Tillyer> Dropped off the meeting (after apologising to subgroup). That amount of totally new info has definitely consumed all the useful parts of my wcag brain for this evening