Meeting minutes
ACT Standup
kathy: Working on the label in name updates. Have had a lot of conversation with CG and AGWG
… Mike's PR is suggesting a change so that if the visible label has text within parenthesis, that text may not need to be included
… different from what we have in CG where the accessible name is different than the visible text
… lots of examples in the PR/issue about how we might pass or fail different things like spaces, abbreviations, etc.
… have not done anything with the github guidance, still linked in the agenda
Chris: Followed up with kathy on assigned rule and working on the oracle implementation
… will get some feedback from Wilco
Helen: Part of the W3C
Daniel: Fixed some links on the WAI website for proposed rules to make sure that they aren't broken
… reviewed a PR from Wilco on AGWG feedback
<ChrisLoiselle> Trevor: Spent time looking at PRs. Also reviewed subjective applicability.
Kathy: Checked in with Todd, sounds like he will back soonish.
Subjective exceptions in the applicability
Trevor: On topic of subjective applicability , discussion 2061 in GitHub
<trevor> https://
Trevor: some cases we have rules , talks to contrast rule. specifically looking at expectation then including the expect if the test target phrasing.
that is more an applicability statement vs. expectation as statement is subjective.
We want to avoid hacking the rules format regarding subjective and objective nature of rules.
… we are looking at more functional, but not so much semantic . Rule Wilco covered was headings looking like a heading, should be a heading.
Kathy: Wilco was covering around functional vs. semantic and the overlap and then an accessible name that was overlapping each but also not applicable to the overlap.
Helen: For label in name, I think that was a CG item.
Trevor: We are getting closer to solving problem. The problem is we are still not near a solution. Showcases 3 list items related objective or subjective applicability , clearly marking for subjective or objective.
… they may be a sub section or follow on section or a pre-approved subjective definitions
… covers Jean-Yves thoughts around sub-sections or formatting and how it may impact rules being written.
… I don't think we can get rid of subjectivity in applicability. What we want to do is limit the ability to hack the format and intended use of these formatting structures.
On definitions reference definitions through pre approved WCAG 2.1 or ACT defined terminology and reference to those in terms of subjectivity and applicability
… any thoughts?
Helen: We are trying to get away from being too prescriptive but at same time want testers to understand why they are testing not necessarily how to .
Trevor: If we define something different than an implementor wants, then we'd want to make the rules and test cases as black and white as possible. Whether an implementor agrees is up to implementor.
Helen: What is the true meaning of normative? Grey areas of WCAG are difficult and that is where the subjectivity comes in.
Trevor: I don't think there is a way to get to the point we want to get to.
Trevor: We want to assume it will happen unless we add additional rails to keep this structured and understandable.
Kathy: The use of the visual heading, the applicability would be entirely subjective. The other example would be if it was decorative. I'm not sure how to create a definition for a subjective term. Perhaps build on what is out there and narrow use of term.
Kathy: you want to add that phrasing in expectation in to the applicability?
Trevor: Yes, but whenever the subjective part is added to the applicability , it is labeled and marked as subjective.
Trevor: Could use our glossary as well.
That would give a guide rail on using a definition .
Helen: Glossary should not be a fixed item. Could be updated per test case update. Lots of terms that are defined in the rule.
Trevor: In order for heading rule, we'd need to define a term for appears as a heading as a defined term. I.e. certain text size, certain other attributes of what "makes a heading".
… Helen and Trevor talk to keeping people honest regarding structured definitions and terminologies
Daniel: On robust as possible, having an idea of subjectivity regarding the terminologies inside the rule itself.
Daniel: Loops of updating rule and terminology seems circular editing
… perhaps separate note to define and state why we are doing it.
Trevor: If we are able to do this, then it would be in a normative document. Glossary is not inside rule but would be external.
Daniel: would be tied closely to it though.
Trevor: Not sure what other document would be. The draft of a rule has a definition , we test and implementor states we need to change something, it would possibly make more work than what we expect.
Daniel: I don't think we would be able to do that on the regular for updating.
Kathy: I like the idea of moving except to applicability so that it becomes NOT applicable.
… talks to non text content rule she is working on . Regarding except if. The SC would say it is inapplicable but our rule would state it passes.
Trevor: Form field error rule states expectation 1 as an example where if it the rule is inapplicable is a pass.
Kathy: how many people need to approve the definitions used for a certain rule? Is it applicable for all other rules? Challenge on maintenance regarding modifications on rule definition and terminology.
Trevor: It would have to go through PR, needs extra work around it. Perhaps setting up fake glossary definitions and then talk to logistics of maintaining it.
Daniel: Plus one to the implementation details of doing all this. Need to verify with Wilco.
Helen: Also should be discussed with CG in terms of expressing our intent.
Trevor: form could change, so CG should be made aware after we get to a stage where we feel comfortable.
Helen: Yes, we just want to make sure they are aware and could give us feedback on blockers we may not know of .
Daniel: CG chairs at least should be involved.
Trevor: Jean-Yves is aware on the stateful new rule part of this discussion.
Helen: I like the idea and the glossary updating would be good progress.
Kathy: Can you talk to stateful rules and the applicability topic?
In stateful, we needed to define what is a status message. So we added in the exception to the applicability.
Trevor: It was a side topic based on rule we chose.
… we will follow up with Wilco.
Secondary requirements and accessibility support
<trevor> kathy: Should we be able to list secondary requirements when their are accessibility support differences
<kathy> https://
<trevor> ... will introduce the topic and we can get into it deeper
<trevor> ... in the rules format draft, we sorted where the rule would pass or fail and talked about how secondary accessibility requirements fit into that
<trevor> ... we currently have specific scenarios, such as the minimum contrast s.c. in the enhanced contrast rule
<trevor> ... discussion here is if we want to add another scenario where accessibility support could determine if an s.c. passes or fails
<trevor> ... unsure what specific examples brought this topic up
<trevor> helen: I think this has been brought up and we have been adding secondary requirements. I know CG has been struggling a bit with some secondary requirements
<trevor> trevor: Is that just on the programmatic side? Wilco did demo a few rules with it working
<trevor> helen: It is there and is possible
<trevor> kathy: I think there is a problem with how it is being displayed and that might be it
<trevor> helen: Does that mean if a screen reader would add alternative text to an image with no alternative text?
<trevor> kathy: The rule that comes to mind for me is the iframe rule where some browsers skip over the iframe but some provide keyboard focus, so depending on the browser you may get different results
<trevor> ... so I think the intention was to allow implementers to pass or fail depending on the browser that is being used to test
<trevor> ... original intention was so that implementers could pass or fail an S.C. based on the rule
<trevor> ... in the case that a tool has multiple tests all at once
<trevor> ... secondary requirements allow for s.c. that are related that implementers may use
<trevor> helen: going back to alt text, some screen readers try to be smart and make their own alt text and you have to disable it
<trevor> ... would another accessibility support include having flags like that being off?
<trevor> kathy: I don't know that the rule should be that specific
<trevor> helen: It should be
<trevor> Daniel: We assume that people are using the default settings because of how many different settings there might be
<trevor> ... getting into the weeds of different settings for screen readers could get messy
<trevor> helen: some of these are becoming the default, and its making things more difficult
<trevor> kathy: I think give this topic some thought, it will pop up next week