07:28:44 RRSAgent has joined #wcag-act 07:28:48 logging to https://www.w3.org/2023/09/14-wcag-act-irc 07:28:48 RRSAgent, make logs Public 07:28:49 Meeting: Accessibility Conformance Testing Teleconference 07:28:54 daniel-montalvo has joined #wcag-act 07:30:29 Jean-Yves has joined #wcag-act 07:39:47 daniel-montalvo has joined #wcag-act 07:41:07 Zakim, what is this meeting? 07:41:07 I don't understand your question, daniel-montalvo. 07:41:25 Zakim, who is here? 07:41:25 Present: (no one) 07:41:26 On IRC I see daniel-montalvo, Jean-Yves, RRSAgent, Zakim, Wilco, ChrisLoiselle, alastairc, Rachael, Github, gonzu_15, blueberryjuice, imlostlmao, sdd, mrlrz, dmontalvo 07:43:46 zainab_ has joined #wcag-act 07:48:11 giacomo-petri has joined #wcag-act 07:55:08 AWK has joined #wcag-act 08:05:26 Hi! Could someone please review https://github.com/act-rules/act-rules.github.io/pull/2111 It is about removing an outdated accessibility support note about menuitem role 08:08:21 Helen_ has joined #wcag-act 08:08:33 present+ 09:02:55 daniel-montalvo has joined #wcag-act 09:15:23 daniel-montalvo has joined #wcag-act 09:33:02 Wilco has joined #wcag-act 09:33:37 Jean-Yves has joined #wcag-act 09:33:37 Topic: iFrames 09:33:41 present+ 09:33:44 CarlosD has joined #wcag-act 09:33:48 Mark: I filed an issue about one of the examples of frame has non-empty accessible name 09:33:58 present+ 09:34:17 giacomo-petri has joined #wcag-act 09:34:19 ... iFrames with role="presentation" the role="presentation" is still focusable in Firefox. It does not get ignore there 09:34:21 present+ 09:34:53 github: https://github.com/act-rules/act-rules.github.io/issues/2096 09:36:01 Mark: Originally Scott wanted to remove role="none" and role="presentation" from frames, but there was pushback from VoiceOVer. It is useful for VoiceOVer and Safari 09:36:14 ... In Chrome it ends up being treated as role="group" 09:36:59 ... The two that don't allow for scrolling if the frame is ignored 09:37:19 ... That is an accessibility issue 09:38:30 ... There are a lot of problems, not sure all of them are inapplicable 09:38:40 Wilco: We know there are browser specific cases. 09:39:13 Mark: One suggestion is leaving the applicability as-is but explaining it further 09:40:30 Jean-Yves: Currently the applicability has an exception that if the iframe is marked as decorative it has a role="presentation" 09:41:03 Mark: It is not clear that that exception in the applicability is because of these issues 09:41:36 JEan-Yves: We don't usually put the reasons in the applicability. Either we put them in the accessibility support or in the background 09:41:48 Mark: Accessibility support could say something to that effect. It is not very clear why the applicability has that exception 09:42:05 ... Is it because of accessibility support reasons or for other reasons? 09:42:12 Wilco: Is there an implementation issue too? 09:42:50 Mark: It came up when we tested it. Presentation role was not consistently ignored 09:43:39 ... There are problems with frames and it seems they will not get resolved anytime soon 09:43:49 Wilco: Resolitions -- We are going to add to the accessibility support section 09:44:58 Jean-Yves: We need to improve at linking accessibility support sections to applicability consideratoins 09:44:58 Wilco: We can make it an actual link 09:45:34 Jean-Yves: Yes. But even in the text when you read back the relation is not very clear 09:45:48 Mark: I'll open a PR with proposed solution 09:47:09 S/Resolitions/Resolution/ 09:47:09 Rrsagent, draft minutes 09:47:10 I have made the request to generate https://www.w3.org/2023/09/14-wcag-act-minutes.html daniel-montalvo 09:47:17 Github: none 09:47:39 Topic: Deprecating Rules 09:48:14 Wilco: WCAG 2.2 is removing 4.1.1 as a whole. For WCAG 2.0 and 2.1 a Note is being added that explains that the SC automatically passes for HTML and XMLthis is not a failure 09:49:11 ... We could deprecate the rule and explain the reasons. Does that convince everybody? 09:49:39 Mark: The overall joy is to get rid of 4.1.1 09:49:51 enrico has joined #wcag-act 09:49:51 Wilco: We are also thinking of deprecating the rule heading has non-empty accessible name 09:50:14 ... We tried secondary requirements. The Task Force considered that was not the right way to use secondary requirements 09:50:49 ... It's either a failure of 1.3.1 or, if it is not, it does not map to anything thus it may be better to deprecate the rule 09:51:39 Mark: 1.3.1 does not deal with visible pixels. I don't think this is affecting anything now 09:51:57 Jean-Yves: There is a conversation about the goal of secondary requirements 09:52:27 ... At the beginning it was OK to either fail or pass, now it seems in some cases they could pass and in other cases they should fail 09:52:42 ... And then we've also used them for stricter success criteria 09:53:43 ... Maybe goals a re not properly defined 09:53:55 Wilco: There be passed examples that would fail the stricter criteria 09:54:13 ... Color contrast enhanced has examples that pass contrast minumum 09:55:16 ... There are three categories: stricter SC, less stricter SC, or some overlap with other SCs 09:56:19 Wilco: Not making accessibility support a reason for moving things to secondary requirements has implications on audio and video rules. That is still a failure even in some cases you don't have the audio playing 09:57:14 Jean-Yves: At some point we should have a rule that form has a label to touch on 3.3.2 or 1.3.1 09:57:47 ... When we made the autoplay rule having only secondary requirements I opened an issue about that 09:58:38 ... If I don't have a label that is a failure of 3.3.2, if the label is not programatically then there is a 1.3.1 failure 09:58:55 Carlos: Shouldn't we have two rules? 09:59:36 Jean-Yes: The distinction for the 1.3.1 case is not that easy, you may not know if you have a label 09:59:37 Wilco: You'd expect at least one of these to be failed 09:59:55 ... I don't think secondary requirements lets us capture that 10:00:19 Jean-Yves: At present you need to at least report one SC -- sometimes it is not sure which one though 10:00:51 Carlos: If I have a methodology that tests only one of those, then I won't fail the examples that are failing the other one, or treat them as secondary requirements 10:00:55 Wilco: Yes 10:01:16 ... IF we want something like that it should be a different thing 10:02:34 ... We've had a similar discussion around 1.3.1 and 4.1.2 10:02:34 ... We ended up not going down that path at all, but we had that conversation 10:02:34 ... This opens up a lot of potential for inconsistency 10:02:51 ... I think I'd split this rule into two for more consistent testing of them 10:03:11 Jean-Yves: But then if we split which SC would we be failing? 10:05:39 Wilco: We just talked about undoing a decision we made in autoplaying audio. We will remove the SC that was under secondary requirements. Any concerns? 10:06:07 Mark: The autopaly one if you are using a screen reader you cannot find the content because of the noise 10:06:24 S/autopaly/autoplay/ 10:07:39 ... This can do some harm, so failing seems reasonable 10:08:46 Daniel: Autoducking feature is a thing in screen reader. We may need to test for consistency of screen readers 10:11:45 rrsagent, draft minutes 10:11:46 I have made the request to generate https://www.w3.org/2023/09/14-wcag-act-minutes.html daniel-montalvo 10:12:31 jcraig has joined #wcag-act 10:12:40 jamesn has joined #wcag-act 10:12:48 present+ 10:12:54 present+ 10:12:58 Topic: BackWard Compatibility of ARIA 10:13:21 MarkRogers has joined #wcag-act 10:13:23 https://github.com/w3c/aria/issues/1990 10:13:29 Jem has joined #wcag-act 10:13:39 present+ JaeunJemmaKu 10:14:22 Wilco: I raised this issue because the removal of aria-expanded being removed from a bunch of static roles 10:14:22 q+ 10:14:22 ... My expectation was that ARIA was deprecating uses of attributes (that was introduced in 1.2). 10:14:40 ... Now some uses were deprecated and others were removed 10:15:00 ... Backward compatibility and keeping clarity on how the spec is changing is very important, it gives us a place to reference 10:15:39 ... We can raise different issues for things that were recommended and are now removed and for things that were recommended but were not used at all 10:17:19 spectranaut_ has joined #wcag-act 10:17:37 present+ 10:18:35 https://github.com/w3c/aria/issues/1990 10:18:40 JamesN: I understand there is a problem. 10:18:50 ... I'd like to know what you expect in terms of types of changes 10:19:08 q+ 10:19:12 ... Normative changes (mast to should) what should be doing? That's the same as removing an attribute from something 10:19:15 ack jamesn 10:19:54 ... I propose to create a list of obsolete attributes in our spec, similarly to what HTML is doing 10:20:09 ... I propose to create a list of obsolete attributes in our spec 10:20:35 ... We previously had some attributes that we don't have a good replacement for 10:20:48 q+ to suggest there could also be aria issues to track changes (at least filing) of issues in implementations and maybe tools 10:21:15 ... the 1.2 ones are because they were a specific use cases, and we needed to work around some technical issues in the implementations 10:21:39 ... If an attribute is not allowed it should not be exposed, whereas these global ones were always exposed 10:22:04 ack me 10:22:04 jcraig, you wanted to suggest there could also be aria issues to track changes (at least filing) of issues in implementations and maybe tools 10:22:04 Matt_King has joined #wcag-act 10:22:05 ... It was heavy work to remove them when they were not needed 10:22:12 q? 10:22:25 present+ 10:23:11 q+ 10:23:11 JamesC: Removal and deprecation is big enough of a step. We could work on an issue tracker that we could use to point to some implementation issues 10:23:38 ... That would help not implementing things that are either removed or obsoleted 10:23:57 ... That could happen even before we even deprecate or remove it from the specs 10:24:14 ... There are templates that Valerie has that we could use 10:24:48 ... Also, maybe we could have some author errors be flagged by browser tools 10:25:08 ... For example, images without an alt attribute 10:25:22 q? 10:25:23 ack me 10:25:38 ... Some of these obsolete attributes can also flag these types of errors 10:26:00 Wilco: Having a maintained list out of the spec might do that. Preference would be for it to be in the spec though 10:26:12 qq+ 10:26:30 ... We ocluid then write ACT rules for things that are obsoleted or deprecated 10:27:00 s/ocluid/could/ 10:27:05 ... We should have expectations for authors and user agents on what to od with obsoleted and deprecated roles 10:27:40 JamesN: When you say list, is it a list of attributes that are no longer supported or you are talking also about normative requirements about child roles for example 10:27:45 ... The first we could do, the second is just the changelog 10:27:48 q? 10:27:48 Wilco: First one 10:28:09 ack jamesn 10:28:09 jamesn, you wanted to react to Wilco 10:28:28 JamesN: If there was a label that we put in our GitHub that could automatically be pulled in the changes of this document, would that be acceptable? 10:28:40 wilco: Yes 10:28:44 q? 10:29:11 q+ 10:29:40 JamesN: Seems reasonable, HTML does it. We should not get into the details as to why, just have the list 10:29:41 ... We should not go backwards retroactively, that is more for going forward 10:29:52 Wilco: I volunteer to go back to track previous changes 10:29:55 ack me 10:30:17 Jean-Yves: I think it's good to have these lists of changes 10:30:45 ... I just care about one ARIA version, but still understand rationale 10:31:05 ... I spend time looking for changes that I need to implement 10:31:40 Topic: Updates on ACT 10:31:52 Wilco: We have gone through your feedback on ARIA ACT, that is now completed 10:32:08 ... We need to reorganise some of the rules. We are almost at a point where we can go for a pass 10:32:13 Q+ to ask the detail of "reorg" 10:32:18 JamesN: Ask for feedback, if you don't get any, that's your feedback 10:32:31 is it template level? 10:32:44 Wilco: A lot of us open issues on ARIA. Any feedback on things we can do to collaborate better? 10:33:13 JamesN: I have not noticed any issues. If you aren't getting responses in the timelines you ned, reach back to us 10:33:38 ... Sometimes a draft PR can be helpful at least to move the issue forward. Not saying we'll accept it, but at least it gives us an idea on how the issue could be resolved 10:33:52 JamesC: If it is a giant PR, let's first discuss. Smaller PRs are easier 10:34:23 q+ to mention JSON data of ARIA 10:34:26 Gemma: What does reorganizationof ACT mean? 10:35:18 ack Jem 10:35:18 Jem, you wanted to ask the detail of "reorg" 10:35:40 Wilco: We split one of the rules up. We took all of the id referencing stuff and put it into its own rule, explicitly looking at what id reference requires the element to the part of the page that exists, for example references to error messages 10:35:45 s/Gemma/Jemma/ 10:35:56 RRSAgent, make minutes 10:35:57 I have made the request to generate https://www.w3.org/2023/09/14-wcag-act-minutes.html spectranaut_ 10:37:08 q? 10:37:08 ack j 10:37:08 ack me 10:37:08 Jean-Yves, you wanted to mention JSON data of ARIA 10:38:10 Jean-Yves: All require context information I use to need to access it programmatically. For example an ARIA JSON 10:38:18 JamesN: That's in our repo. 10:38:18 ... If you run any Respec version that will show it to you 10:38:18 ... We only regenerate when we publish a new version, it still is 1.2 10:38:24 Rrsagent, make minutes 10:38:25 I have made the request to generate https://www.w3.org/2023/09/14-wcag-act-minutes.html daniel-montalvo 10:38:31 MarkRogers has joined #wcag-act 10:41:01 https://www.w3.org/WAI/standards-guidelines/act/rules/ 10:41:01 Matt_King_ has joined #wcag-act 10:53:30 q+ to talk a little about required context role rule 10:54:01 ack jamesn 10:54:01 jamesn, you wanted to talk a little about required context role rule 11:48:34 Matt_King has joined #wcag-act 12:00:12 trevor has joined #wcag-act 12:15:27 daniel-montalvo has joined #wcag-act 12:19:35 daniel-montalvo has joined #wcag-act 12:34:10 thbrunet has joined #wcag-act 12:35:43 CarlosD has joined #wcag-act 12:35:46 Wilco has joined #wcag-act 12:35:47 suji has joined #wcag-act 12:35:47 kathy has joined #wcag-act 12:36:31 agenda? 12:36:38 Jean-Yves has joined #wcag-act 12:36:47 present+ 12:36:50 present+ 12:37:36 present+ 12:37:36 scribe+ 12:37:36 present+ 12:37:46 present+ 12:37:50 present+ 12:37:55 agenda+ End time on Friday 12:37:57 agenda+ Subjective applicability (Trevor) 12:38:01 agenda+ Refining secondary requirements (Kathy) 12:38:01 agenda+ Defining consistent / partially consistent (Wilco) 12:38:08 zakim, take up next 12:38:08 agendum 1 -- End time on Friday -- taken up [from Wilco] 12:38:30 Wilco: How long do we want to go for tomorrow? 12:38:49 ... I might need to leave before six 12:40:01 Jean-Yves: We can end the agenda at 6pm and if someone wants to stay in the room they can 12:40:13 ... and perhaps we can start at 2pm 12:40:22 Wilco: I'll update the agenda 12:40:23 zakim, take up next 12:40:23 agendum 2 -- Subjective applicability (Trevor) -- taken up [from Wilco] 12:41:09 giacomo-petri has joined #wcag-act 12:41:46 Discussion: https://github.com/act-rules/act-rules.github.io/discussions/2061 12:41:46 https://github.com/w3c/wcag-act/pull/539 12:42:50 trevor: In the current rules format we have an objective applicability requirement 12:44:07 ... with subjective applicability we can have situations where the applicability scope is too broad (e.g. non-text content) 12:44:56 ... in the current rules we do have similar situations where parts of the applicability are moved to the expectation 12:45:35 ... for example the text has minimum contrast rule which has an "except if the element is..." 12:46:01 ... so we ended up hacking our rules format 12:46:16 ... other issue is that we could not write some rules 12:46:49 ... for example "this rules applies to elements styled has an heading" which we couldn't objectively define 12:47:04 s/has an/as an 12:47:27 MarkRogers has joined #wcag-act 12:49:50 https://github.com/w3c/wcag-act/pull/539/files 12:54:22 trevor: The first major change proposed in the PR is allowing subjective forms in the applicability 12:55:10 ... these subjective forms are ways to capture subjectivity that we have used in our rules 12:55:43 ... in each of the forms we start with an objective target and then we apply the subjectivity on top of it 12:57:22 ... The second part of the changes is the requirement to define the subjectivity in a glossary 12:58:07 ... this aims to have a group consensus preventing individuals to define subjectivity by themselves 12:58:52 Jean-Yves: In the discussion we converged to requiring subjectivity to be expressed in a standard format 12:59:30 ... But if we need to update the formats of the subjectivity in the future we might not want to have this in the rules format for flexibility 12:59:36 q+ 12:59:42 ... similar to what we have with the common input formats 13:00:09 q+ 13:00:27 trevor: In the TF we agreed that we should have it in a note or similar 13:01:03 daniel-montalvo: I agree with that approach 13:01:09 q+ 13:01:19 ... otherwise this would need to go through AGWG at least 13:01:23 ack daniel-montalvo 13:02:04 Wilco: This idea feels like extra paperwork to remind us that we should write good rules 13:02:21 ... I'm not sure there is extra value in this 13:02:49 Jean-Yves: Compared to what? Not having a list of allowed formats? 13:03:23 Wilco: I'm not sure that would be the solution either. 13:03:30 ack Wilco 13:03:31 ack me 13:04:05 trevor: If we could all collectively agree that we are going to write good rules, perhaps we don't need to express this in the rules format 13:05:27 q+ 13:05:34 ... would we be comfortable with just updating best practices documents? 13:05:51 ack thbrunet 13:07:11 thbrunet: If we require subjective things to be defined we could get away without having the required subjective form 13:07:43 ack Jean-Yves 13:07:58 Jean-Yves: I like having some sort of gate keeping 13:08:19 ... we do not always agree with how things need to be formulated 13:08:34 ... what is too much or enough subjectivity? 13:08:48 ... Do we want to discuss that every time we review a rule? 13:10:32 MarkRogers: What about how automated tools would deal with subjectivity? 13:11:13 q+ 13:11:21 q+ 13:11:22 Jean-Yves: That is something we might discuss later... but agree that objective is automated, and we should strive to have most objective rules 13:12:48 Helen_: Agree that is creates more overhead, but it also better supports traceability of the decisions we take when writing a rule 13:13:07 ack Helen_ 13:13:48 Wilco: Maybe we could put some constraints around what kind of subjectivity is appropriate 13:14:22 ... I earlier advocated for the creation of a list of approved examples 13:14:38 ... which we could update whenever we find another example that should be considered 13:15:40 ... this way we could list aspects that a tester could examie 13:15:46 s/examie/examine 13:17:14 trevor: In the PR we have the requirement that when you use a subjective form you need to list what characteristics need to be matched 13:18:35 ... We could use other alternatives, such as using logic operators to organise the characteristics 13:19:19 q+ 13:19:25 ... another alternative is using scoring, where alternatives would have points and you need to reach a gola score 13:19:32 q+ 13:19:39 ack Wilco 13:20:50 ... yet other is specifying characteristics that the element needs to have without expressing a formula or score 13:21:09 ack thbrunet 13:21:13 q+ 13:21:35 thbrunet: The more I read this it feels like were trying to make something subjective into objective 13:22:32 trevor: My goal is we have something more concrete for implementors justifying why they are classifying something as applicable 13:23:09 thbrunet: We all have our nuances, as long it matches the fails and passes... I don't think we need to build classifiers 13:25:39 trevor: Would you be in favor of including concrete examples as part of the definitions? 13:25:39 thbrunet: yes 13:25:39 Jean-Yves: I also like the "getting warmer" method 13:26:13 ... possibly with "getting colder" examples also 13:26:21 MarkRogers has joined #wcag-act 13:26:28 ack Jean-Yves 13:26:32 q+ 13:26:38 q+ 13:28:10 Jean-Yves: We should try to reduce the space for information to be as small as possible 13:28:52 s/information/interpretation 13:29:31 Jean-Yves: The examples are good for creating boundaries and promote discussions, as we already do in the rules 13:29:34 trevor: Do you still like the subjective forms and the definitions are enough? 13:30:27 Jean-Yves: They go together, and I feel we should have both 13:30:58 s/forms and the/forms or the 13:31:19 Jean-Yves: For the subjective definition we will need examples 13:31:22 ack Wilco 13:31:52 Wilco: This impacts manual evaluation, so I would like to know from manual testers 13:32:07 ... I like the simplicity of the getting warmer approach 13:33:11 ... it closes the definition, anything that does not have the specified characteristics is not what the definition applies to 13:33:42 q? 13:34:06 ... I would like to have a new term such as "closed subjective" to distinguish from what we already have 13:34:09 ack kathy 13:34:25 kathy: I'm leading towards the logical approach 13:34:36 ... when would a tester know they are getting hot? 13:35:03 enrico_ has joined #wcag-act 13:35:13 ... the logical operators method is mostly tied to how we define a concept 13:35:55 ... in the getting warmer how do we know how many of the characteristics need to be present? 13:36:40 trevor: Would it help if we had examples stating what characteristics are met in each example? 13:36:45 MarkRogers_ has joined #wcag-act 13:37:01 kathy: That seems what is described in the logical approach 13:37:30 q+ 13:38:06 kathy: Nevertheless, examples will all be helpful 13:38:09 ack MarkRogers_ 13:38:09 thbrunet_ has joined #wcag-act 13:38:15 ack MarkRogers 13:39:09 MarkRogers_: The logical approach could be biased towards headings and western characters 13:39:19 ... the getting warmer is more extensible 13:39:23 ack Wilco 13:39:33 q+ 13:39:42 Wilco: The alternatives need not be exclusive 13:39:55 ... we could use different alternatives for different instances 13:39:59 q+ 13:41:05 ack Jean-Yves 13:41:44 Jean-Yves: We may need to have a format as a guideline to writing close subjective definitions 13:42:59 Jean-Yves: We can mix the logical and getting wormer saying something like "the concept usually has at least two of these characteristics" 13:43:08 +1 that feels like a great middle-ground 13:44:00 q? 13:44:15 Jean-Yves: But it's good to have the ability to express something logically when needed, and be more flexible when not possible 13:44:22 ack Helen_ 13:44:39 q+ 13:45:06 Helen_: The more information I give testers the more they can make decisions for themselves 13:45:48 ... a simpler definition seems to be better 13:47:43 ack Wilco 13:47:57 Headings work a bit differently in Japanese: https://www.w3.org/TR/jlreq/?lang=en#hanmen-design 13:49:10 suji: I like the combination of getting warmer and logical 13:49:46 s/they can make/they cannot make 13:52:11 CarlosD: The flexibility of having the possibility of having logical when possible and getting warmer when not is a positive for me 13:55:14 q+ 13:55:20 q+ 13:55:28 Helen_: If we are too prescriptive we will need to be exhaustive, otherwise the chances that people mess up when applying the definition will grow 13:57:03 Wilco: Passing a rule does not meaning meeting a success criteria, so having definitions that restrain what we test is not a problem per se, as long as we can keep expanding what we are able to test 13:57:30 ack Wilco 13:58:12 enrico_: I like the getting warmer too 13:58:58 ... but for each characteristic the text might not also be objective, so we should also explain the subjectivity in the characteristics listing 13:59:16 ... giving examples would be very helpful 13:59:25 ack enrico_ 14:01:21 Jean-Yves: Agree that we should make as explicit as possible what defines each characteristic 14:03:06 q+ 14:03:43 enrico_: do we need to specify weights for the characteristics? 14:04:05 Jean-Yves: I don't think we will be able to find the correct weights 14:04:24 q+ 14:05:23 Jean-Yves: but nothing prevents implementers to define their own weights 14:08:10 ack Wilco 14:09:35 Wilco: We have rules where we explicitly exclude things because they are edge cases and we not sure how to handle them 14:09:35 s/we not sure/we are not sure 14:10:09 Wilco: We are coming to an agreement, with Helen being an outlier 14:10:15 ... I would like to talk to Helen later 14:10:20 ack MarkRogers_ 14:11:13 MarkRogers_: In the CJK domain headings work differently 14:11:35 ... so coming up with a set of conditions that work on everything might be difficult 14:11:45 Wilco: We don't need to make it work on everything 14:11:59 Jean-Yves: We can specify to what it applies 14:12:34 trevor: I want to revisit the subjective forms to see if they are still needed or how they can be improved 14:13:02 ... and I have a list of points to work on 14:13:42 ... like explore the concept of closed subjectivity 14:13:51 s/explore/exploring 14:14:08 Wilco: Any further comments? 14:14:37 Helen_: Having too many points makes it hard to mantain 14:16:19 s/hard to mantain/hard to review and hard to read 14:16:19 zakim, take up next 14:16:19 agendum 3 -- Refining secondary requirements (Kathy) -- taken up [from Wilco] 14:16:19 scribe+ 14:16:49 kathy: we started talking about secondary reauirements. Requirements that are related to a rule, but not specifically tested by id. 14:17:00 ... they are often reported in implementation. 14:17:58 ... Draft format to add secondary requirements to rules 14:17:58 https://w3c.github.io/wcag-act/act-rules-format.html#outcome-mapping 14:18:51 Rrsagent, draft minutes 14:18:52 I have made the request to generate https://www.w3.org/2023/09/14-wcag-act-minutes.html daniel-montalvo 14:20:07 https://github.com/w3c/wcag-act/pull/542/files#diff-4f84b10f4fa5880bac20c3a8b3e31671a67e8bfce9b5d8e67519b1c513f1ed6bR265 - update for how to provide explanation 14:20:17 https://github.com/w3c/wcag-act/pull/540/files - additional update for accessibility support 14:21:01 S/reauirements. Requirements/requirements. Requirements/ 14:24:08 https://github.com/act-rules/act-rules.github.io/discussions/2095 - discussion and decision to not include accessibility support 14:37:08 daniel-montalvo has joined #wcag-act 14:58:22 Rachael has joined #wcag-act 14:58:28 Jem has joined #wcag-act 14:58:38 AWK has joined #wcag-act 14:59:00