Meeting minutes
Intros and Annoucements
<alastairc> Update to proposed charter: https://
alastairc: announcement - there was an update to the proposed charter. link above.
Subgroup updates
GreggVan: Purpose is to publish a candidate recommendation. Can you explain what a candidate recommendation snapshot is?
Kevin: First stage is a candidate review snapshot and it's the stage on from a working draft. The next stage is then candidate recommendation draft.
<Wilco> +1 Gregg, this is very confusing
<bbailey> Here's a candidate recommendation snapshot for WCAG 2.2: https://
GreggVan: Asks for clarity between the three different stages for charter publication.
<alastairc> q/
<hdv> more info on different types on the recommendation track can be found in the Process: https://
<bbailey> From that 2.2 snapshot: "A Candidate Recommendation Snapshot has received wide review, is intended to gather implementation experience, and has commitments from Working Group members to royalty-free licensing for implementations."
Kevin: Candidate recommendation snapshots and drafts are two variations of a candidate recommendation. Multiple versions of these may be published and have multiple layers of feedback. Draft means its ready for a wider community review and feedback.
<alastairc> Also worth noting that there is no "PR" stage anymore, so there are likely to be more CR drafts.
<hdv> (capital-P Process is what manages what different types of docs exist at W3C)
<julierawe> brb
GreggVan: Needing more clarity on timing.
<bbailey> Here's the PR: https://
<bbailey> (Press Release, not pull request)
GreggVan: Goal is to have formal recommendation for WCAG 3 in the next 2 years.
Kevin: yes, for wide, community review.
<julierawe> i'm back
alastairc: It's expected that there are more candidate review documents within charters.
<Zakim> bbailey, you wanted to mention we did this for WCAG 2.2 -- if not other AG docs
<Zakim> hdv, you wanted to say what's in charter matches what's in process
bbailey: Process has been followed before with 'snapshot' - included links above.
GreggVan: What are the consequences, if any, of us failing to get to a candidate document in 2 years? Are we setting ourselves up for failure since there's so much left to do?
Kevin: Consequence isn't clearly defined within the process. Will follow up. There are approaches to that interns of extending the charter to address the deliverables, or accepting where you are at the time. May be a reason to re-charter.
<Wilco> +100 Gregg
GreggVan: Concern is that we may set something that's way less than what we can reasonably achieve, and people might be mad at us because we aren't moving forward. Concerned about the reputation of the group. WCAG 3 is so important and he wants it to be a solid published recommendation.
<bbailey> Maybe a comparable snapshot: https://
hdv: Dropped the link to the W3C Process (https://
alastairc: As for the timeline, personal perspective is that WCAG 3 is 80% solid, and the last 20% is where refinement happens. Subgroup updates. One provision per person per subgroup per month will keep us on target.
alastairc: ... chairs continue to monitor progress, and it is a reasonable pace to make the timeline.
<hdv> +1 janina (CG link: https://
janina: W3C process is defined in the document. There's a community group that people can join where the W3C process is discussed and edits are proposed. Janina is part of this community group.
<Detlev> Note to alastairc: there are lot of less active WG members so that distribution "1 req per person per month" may not work that easily
alastairc: Clarified that WCAG 3 is moving forward in the defined Advisory Board process.
Wilco: Sounds like a wide review draft, and not necessarily a CR. Why is this not a wide review draft? Why is the goal to go beyond that?
<Zakim> Rachael, you wanted to say there are two differences we are talking about
Rachael: Members have a different understanding of what a CR is. The schedule is aggressive. We prioritize provisions from WCAG 2.2.
<kevin> https://
<alastairc> Detlev - yep, we've got an editor group that is keeping an eye
Kevin: Replying to Wilco's comment, there's no such thing as a wide review draft, it's not a thing. As for Alistair's comment, yes, it is aggressive timeline, but it's doable. As for Greg's comment, we are always criticized for whatever we do. It is not a specific maturity stage.
<Zakim> GreggVan, you wanted to say beed better title for 2.6 it kind of looks like
ACT workshop https://docs.google.com/presentation/d/17IPpA7IvvlI-MPeVdwepawr4OobBV0aV/edit?slide=id.p1#slide=id.p1
GreggVan: Different topic: Wording for the other activities need clarity.
Subgroup updates
<kevin> GreggVan, I will change that for clarity
alastairc: Subgroup updates are next on the agenda. The facilitator for the subgroups are asked to go in queue, and provide a status update. Callout any blockers.
alastairc: For the User Control and Prevent Harm subgroup. Tackling flashing, animation, and progress on updating the core normative text, flushing out the methods, and refining the tests. People came in and provide their lived experience that weren't covered in the current definitions, triggering research needed to define the intensity and speed
… and frequency. Working through member comments.
hdv: For Error Task Completion and Help subgroup. Tackling definitions, shifted to addressing issues that were filed by our group. For example, saving progress when working on the form. No blockers at the moment. Will continue to go through issues.
<hdv> (Oh and forgot to say: if anyone wants to dive into Errors and task completion, my subgroup welcomes new members, do feel free to get in touch / join!)
giacomo-petri: For User Orientation, Structure, and Layout. Worked on definitions, and now reviewing issues raised during the draft review.
<Zakim> kevin, you wanted to update on Sign Language
Kevin: For Sign Language subgroup. Starting from a blank slate. We're dissecting user needs into requirements. We need to do more in terms of providing additional requirements to ensure they're covered. Blocker is that we have no one that uses sign language in our group. Two potential candidates.
Makoto_U: For Image and Mediate Alternatives subgroup. We have 38 requirements and assertions in total. Media has 14 requirements and assertions. Reviewing definitions and short names label. Two questions have been raised. Do we need to split some questions into available and equivalent? Addressing specific questions around the dependencies of the
… requirements to each other for speaker identified, language of speaker, etc.
Rachael: For Single Sense subgroup: Split up member assignments, and outreaching to offline members. Researching and shepherding research to make final decisions.
<alastairc> Francis: We have divided up all the relevant provisions into their guidelines. I asked, as homework, for subgroup members to pick a guideline or two to be responsible for and start work on, but only Adam has started that so far. The subgroup is meeting tomorrow, and I’ll re-emphasize that there is an expectation of asynchronous work between subgroup meetings.
julierawe: Text and Wording Subgroup. Drafting, revising, and replacing definitions for terms. Working to understanding terms. Provided feedback to the AG chairs on the proposed definition of 'content' and inconsistencies throughout WCAG 3 in the way glossary terms are used in multi-word phrases that include the word 'content.' Beyond definitions,
… changes to provision types from core to supplemental based on the Oct WCAG 3 exercise, January survey, and comments from AG meetings for 3 requirements. Added GitHub issues to consider more provision-type changes. Also started internationalization work, and took over the text appearance section from another subgroup and are developing a plan to
… research metrics and which languages are included. Need time to ramp up that work and get the language metrics. Sub group members are not native speakers of those languages. Members are starting to claim individual provisions and getting that ramped up. Goal is to do asynchronous work to keep moving forward.
alastairc: Input and Focus Group. Divided up the provisions and for members to pick a guideline they are responsible for, and work asynchronously.
ACT workshop https://docs.google.com/presentation/d/17IPpA7IvvlI-MPeVdwepawr4OobBV0aV/edit?slide=id.p1#slide=id.p1
alastairc: ACT workshop handed to Jean-Yves.
Jean-Yves
Kevin: Recording this session so that people not present can view the material. Encourage people to raise questions in IRC. Starting recording.
<julierawe> Thank you for recording the ACT workshop!
Jean-Yves: Introduced himself. Works at Site Improve in Denmark. Met some of members physically, and also active on Slack, and GitHub by the name of Jym77. Work at Site Improve in accessibility testing for 6.5 years. Knows how accessible name is computed, but not if it is descriptive or not.
Jean-Yves: ...Format definition.
Slideset: https://
Jean-Yves: Important bits: Applicability, expectations, examples, and definitions.
Jean-Yves: Example: Image has name applicability and exception.
<julierawe> Does ACT require that exceptions be included as part of applicability? We split them apart
julierawe: Split apart 'applies when' and 'except when' - is this the correct format?
Jean-Yves: format doesn't have this currently. it's a matter of presentation. we felt it wasn't needed. it's a matter of style of where it is put in the rule.
<Wilco> +1 "except when" fits perfectly well within applicability
julierawe: Added this approach to be clear.
Jean-Yves: Could have some presentation trick if it's very clear that we have a list of exceptions as the last part of the applicability, not in a separate section.
alastairc: Test will be more specific than the normative, so not worried about a difference at this stage.
Jean-Yves: ACT rules main principles: unambiguous. Example of title, doesn't tell what a title is. When we write a rule, we have to resolve the ambiguity
Jean-Yves: Secondary principles: avoid subjectivity when possible, keep rules simple and atomic. The rest of the rule must be clear. Be objective and unambiguous. For simple and atomic, split into smaller requirements, avoid a rule being required by another rules. Avoid multi-level logic.
Jean-Yves: ACT Rules Limitations. First limitation is the focus on Web technologies, and later for mobile app, PDF, Word, etc. Definitions are different, techniques are different. Second limitation is that rules are not test procedures, so they don't tell you how to reach the conclusion, they just focus on the outcome. Describe what it means to
… pass the rule but it doesn't provide how you test (such as manual testers). Last, the rule is to detect failure, not for 'passing.'
Jean-Yves: Rules can get very technical. Walked through an example of how something could become technical very quickly.
Jean-Yves: Examples are part of a rule. Checked to verify their implementation. Testing technique types (manual, etc), agreement among examples.
Jean-Yves: Testers can implement the rules. Vendors can send an implementation report. Shows they showcase that we are correctly following what is happening. Half a dozen tools are shown to show there is consistency on a specific rule and there is consensus.
Jean-Yves: Backed by Examples. Results would provide an expected example. When we get to discussing if something needs to be changed or not in the rule, we have a very concrete and precise test case.
Jean-Yves: WCAG 3 work in practice. Work organization. It is the subgroup's responsibility to write the rule. The liaison will meet regularly with the group to answer questions during subgroup meetings. Format changes are possible, but changing it is complex.
Jean-Yves: Work focus. Only write rules for web technologies. There's a rule template to get things going. Suggest starting with authoring examples. Usually there are at least 2-3 examples for each rule. Full definitions can take a lot of time. Timeline is ambitious.
Jean-Yves: Re-use existing work. Look at existing rules and existing definitions. Use the specifications in your definitions. When you write, use the specification to simplify the complex rules.
alastairc: Rachael asks is there's a generic version for these requirements?
Jean-Yves: No, but we may be able to specify upon technologies, otherwise we are at the risk of being quite ambiguous
… The important bit is for it to be unambiguous, if we can be unambiguous without bein tech-specific that's fine
LoriO: If ACT is putting together the testing, why do we have a separate tests in WCAG 3?
Jean-Yves: Understanding documents came first. ACT was born to harmonize the tests, we need something more precise than current understanding documents
alastairc: Both groups are in coordination
… In WCAG 3 wwe are defining top-level requirements, ACT has more granular tests, we're working our process
kenneth: In WCAG 2 (informative docs) we use mappings from ACT at the bottom of each SC understanding page. Not ssure if we'll be doing this for WCAG 3
alastairc: That's for you and Kevin to discuss
GreggVan: Would appreciate more guidance when we receive review requests from ACT, especially the ones at the edge
<Wilco> +1 good tip Gregg. Will keep that in mind
Jean-Yves: If there's a conflict between ACT Rules and WCAG 2, WCAG wins. There shouldn't be any conflicts. When something's not clear enough for us we do raise issues to WCAG
… For WCAG 3 that might change a bit as my understanding is for the rules to be at the very core of the requirements
<alastairc> This is an example of where ACT has raised an issue to get clarification: w3c/
Jean-Yves: Difficulties we've encountered:
… Assumptions -- usually a way to park some of the complicated edge-cases
… A lot of nested "if" clauses may warrant an assumptions section
… Two examples of assumptions are in the page language with exceptions for when the page language is set by http headers
<Wilco> Importantly, we know setting language through HTTP headers does not work
Jean-Yves: Another one on the title when it's not specified for the email subject in HTML
… Consider using assumptions but don't use them if they are really part of the rule
GreggVan: 5% is about a billion pages
… I am worried that there shouldn't be any assumptions
… If you identify assumptions we should put them under "except" conditions
… WCAG says: when this is true, you apply the rule
Jean-Yves: Fair point.
… It is a matter of what we can test (talking as an automated test tool vendor)
… Sometimes we just have acccess to the crowled pages
… We can put them in an "except-if" clause, but it's very difficult to ddescribe all the cases, for example, all the headers that exist
… Some things are very difficult to express as part of the rules
… In this case we are going to say that the page doesn't have a lang attribute, which is accurate, even if it has an http header defining the language
Wilco: It comes down to things that we rarely see in practice
… More a theoretical issue
GreggVan: We're talking about the things we can automatically test
… Assumptions would be the things you need to manually check
… We should figure out which ones to use in WCAG 3, I think preconditions are a better approach
Jean-Yves: Pretty much, few rules use assumptions, the goal is to be able to minimize their use
Jean-Yves: Number of examples -- when there are few examples sometimes it means it can be ambiguous
… We often add examples to record decisions (for instance empty headings) when we reach a conclusion we'll be adding examples to the relevant rule to illustrate
… If you use too many exxamples then the rules may become unreadable
… It is a difficult balance, I think we need to decide on a case by case basis
Jean-Yves: We may go with fewer examples for now as this project's got aggressive timelines
Jean-Yves: Rule don't distinguish between testing procedures (manual, automated or semi-automated)
… But we do distinguish internally
… So far we haven't been good at writing manual testing rules
… With the level of expertise in the group it's been easier to focus on the technical part
Jean-Yves: Issues to keep up with evolving specifications -- example is combo box specs for ARIA
… ARIA 1.2 is REC, but people are already using and implementing bits of 1.3
… With HTML is more difficult, as it is a Living spec
… We tend to signal the date when something is included to try to keep track of spec updates
Jean-Yves: Rules must be unambiguous, it can be difficult not to get into fine details
… We need to know fairly fast the scope of the rule, definition, description, examples, expectations etc
… Your ACT liaison will help
<julierawe> https://
<Zakim> julierawe, you wanted to ask Jean-Yves about existing ACT rules
julierawe: I just pasted the link of the existing rules into IRC
… There's 87 rule, 34 are approved, 35 are proposed, 15 are beyond WCAG, and there's a group for WAI-ARIA
… This is all related to WCAG 2. A large number are still in the proposoed phase, and some aspects in WCAG 2 don't appear to be represented. Whic is the pace at which ACT has been working in WCAG 2? How do you see this translating into the WCAG 3 work?
Jean-Yves: ACAT has been working quitte slowly in the last couple of years. We were quite active in the 2019-2022 range, because of EC funds
… We are now in a maintenance mode. For WCAG 3 we hope we can have new people and move faster
… Not sure though about how fast we will be
… The goal has neve been to stop at that point, it's just we are shifting to WCAG 3
… For WCAG 2, we also want to change the approval process a little bit to make the process smoother
<Zakim> alastairc, you wanted to ask where the listing is, as each sub-group can find already-written rules that might be applicable... and to also mention "accessibility support sets"
Jean-Yves: Implementations are a concern, our process asks for three implementations
alastairc: I just pasted some links for people to get started
… So far they've been quite technical. A lot of sub groups may be using the format and focusing more on manual testing, maybe a little bit more generic. If that doesn't fit the format, we may want a different type of format
… In WCAG 3 we have accessibility support sets
… These would include most common ATs, browsers, etc
… If we are proposing a method, it should work with the AT and user agents in that accessibility support sets
… Do you think this impacts ACT rules?
Jean-Yves: We have the accessibility support concept, but it's different. It's more focused on whether some AT/browser combinations don't work in the expected behavior
… We try to avoid putting exxamples that target this very problem, as these would throw different results depending on the combination used
… Probably there needs to be more exhaustive documentation
… To you point, I don't think this goes against our rules, it could make it even easier to write rules as we better scope the scenarios via accessibility support sets
alastairc: As a next steps, I'd propose that each sub groups takes this on at their next meeting
… Will liaisons be joining weekly sub group calls?
Jean-Yves: I think they'll be joining the meetings when they're needed
Wilco: Liaisons ans sub group leads will have to coordinate on when it would be worth for ACT liaissons to participate. Relevant intros would also be worthy
alastairc: Sounds good. Next probably three weeks that's going to be key
<Zakim> bbailey, you wanted to ask about template
alastairc: We'll try to support that. We may use part of this very meeting in three weeks time to see how things are going
<alastairc> Templte ^
Wilco: We are going to look at that document in ACT this week, it may change
<janina> Wanted to ask about recording availability
<Wilco> Thank you Jean-Yves for the presentation
janina: Recording availability?
<bbailey> that great -- i didn't realize we were already using ACT rule format outline !
alastairc: Kevin's going to put this in our google doc area and will send the link
Francis_Storr: Would be nice to get the link today for the sub group meetings tomorrow morning
julierawe: How soon can you send the recording?
kevin: I'll try to get it as soon as possible
<julierawe> Thank you kevin
kevin: No captions but we do have minutes, hopefully that suffices