Meeting minutes
ACT Standup
<Wilco> act-rules/
Wilco: Various little things. PRs, reviewing, and I set up a practice repo
… I'll add people later
… I worked with some of the EO folks on getting the ACT rules information pulled directly into the Evaluation Tools list
<Wilco> https://
Wilco: You can filter out based on tools that have ACT support
… Then you can click "Show more details" and you see more implementation details, including the number of rules supported and its consistency
Daniel: Yes, the sooner it goes out the better
Kathy: Updated GitHub for ACT guidance document with Daniel's feedback to add the sample rafts for review
… Available for comments, I will add your link, Wilco, thanks for doing that
… AT some points we may want some thoughts on what we want on this practice repo
… I did some cleanup of Trusted Tester implementations
… I will be attending the CG for label in name discussion
Chris: Working on implementations for Oracle. I hope ot get that done during the month
… I looked at the "how to" no comments from me
… I will contribute to the repo and see if there are any issues with what is written there
Wilco: I'd really like to see a preview of that before you put mor work on that. Could you share that JSON file?
Chris: Yes
Trevor: Started polishing some of my PR and answering to Wilco's feedback
… Trying to find a workaround for a double negative
… Started to add subsection to the discussion on applicability
Daniel: GitHub guidance
… Likely picking up some of the draft items to write
Do we have a meeting next week?
Trevor: I'll be here
Kathy: I'll be working
Daniel: I'll be working
Wilco: We will have a meeting next Thursday
Subjective exceptions in the applicability
<trevor> https://
Trevor: The exception sub section is subjective
… Is this section require and if so under what cases might we use it?
… Some of the rules that I looked at are using either assumptions or expectations to go over the non-objective edges of the applicability
… Are there any ways we end up misusing exceptions?
… Form field error indicator rules: It has three expectations and all of them say pretty much the same
… Because the definition is subjective it cannot go in the applicability, and gets pushed into the expetation as a pre-condition
… You find something that is applicable and you call it your test target, and then you put a pre condition to decide whether or not you should even test it
Wilco: This probably the worst example
Trevor: This is why I started here
Wilco: This should be in the applicability itself. This rule is about form fields that have a form field error indicator
Trevor: Interesting point. IF we only were to add the exception we would still not be able to add that to the applicability
Wilco: Yes.
Trevor: I'd rather have one sentence inside of the exception rather than all throughout the expectations
<trevor> https://
Trevor: Blocks of repeated content: Its applicability is any HTML web page
… Inside of the expectations is really the applicability of the rule: each block of repeated content
… Does everybody agree that this should be the applicability and not the whole HTML page\?
Wilco: Not sure. This was also meant as an objective definition
Trevor: It is not objective
Trevor: IF we were to allow the exception, the applicability would still be any web page, and the exception would be the ones that don't have a block of repeated content
Wilco: I remember why this was done. IF there is a global mechanism that hides everything you don't need a skip mechanism for each of the blocks
… We don't want to require that each repeated block of text have its own mechansm, you could have a general one
Trevor: The exception section may help make the rule more readable
… For the forms rule it is more painful to parse, for this one I am not convinced. I don't think this rule is that difficult to read
Wilco: Is it more difficult to understand?
… I think it is fair to say that if there is not repeated content the rule shouldn't apply
Kathy: Can we just flip it around and make it in the possitive?
… This rule applies to web pages that has blocks of repeated content
… The possitive phrase is more understandable
Trevor: We may make the entire applicability subjective
… The current at least has half of the applicability objective and concrete
Kathy: What if you still keep the objective part objective?
… When I see the exception you are still introducing subjectivity
Trevor: We'd have to make it additive
… I'd need to think about it more
Wilco: I thought of allowing subjective applicabilities to the expectation
… Now we have rules with things like a button role must have a descriptive accessible name
… but we can't say things that look like buttons are marked up as button
… The look like a button is subjective and we cannot fit it into the applicability
Trevor: When you were originally writing the expectations, do you remember why they were subjective?
Wilco: It was the idea that much of accessibility testing requires to decide if something is equivalent to something else, and that in itself is subjective, and that seemed like the actual thing to test
… We wanted to make these rules as strict and tight as they could be
… We wanted to avoid as much of the ambiguity of some of the SCs, that's why we decided the applicability should be objective
Trevor: A lot of the times rules start off with a definition of something and then others where the applicability works they start just with "for each test target"
… For the exception that we have why we can't just put it in the assumptions
… Because the assumption qualifies the test target. We are pushing some of the applicability into the assumption
… If we allowed expectations to be subjective we could include some of this
Wilco: We don't want to make assumptions when the edge cases we are ignoring aren't theoretical
… We have been working around the limitations of the Rules Format. Some of them we have put into the input aspect
Trevor: Like the language
Trevor: I am trying to figure out a way for this rule to still be written and making them more readable
Chris: I am following. I get why we are doing it
Kathy: What if we do a combination of the two ideas?
… We have the applicability and ten in the assumptions we include the subjective part?
… I think the assumptio by itself would lead to more false possitive than we want
… And the possitive approach would narrow those, still would not eliminate them completely
Chris: As per heading is descriptive, that is up to the tester to define.
Trevor: I think next steps are for me to rewrite some applicabilities and expectations for this rules based on today's feedback
… I get that the exceptions sub section is difficult to understand
… Wilco, we may need to have an hour to go through this
Wilco: We can continue this conversation, we don't have anything time sensitive
Wilco: If we were to say either your applicability or your expectation has to be objective. Could we make these use cases work?
… Maybe some of the things we have done in one rule should be split into separate rules
… Let's start with the error messages rule
Trevor: We can pull the error indicators into the applicability
Wilco: Would it be useful to say that the expectation needs to be objective?
… We can't just pull the form error into the applicability, the expectations are not objective
… Is there a way that we can split this that makes sense?
Trevor: "text that is visible" and "text that is inclued on the accessiblity tree or accessible name or description" -- These pre conditions could work.
… IF we were to split this, we can work with the applicability and then ensure it has these two things above
Wilco: It does not work very well
Trevor: Feels like we are pushing the expectation into the applicability
Wilco: What if only some rules are allowed to be subjective?
… We would clearly indicate that they are, and we wouldn't allow for all of the rules
Chris: We would need to categorize them very carefully
Trevor: I stil prefer to "quarantine" some of the subjective parts rather than allowing for more subjectivity
… This way some of the rules that are at the edge would fall into more subjective approaches
Wilco: How much should we care about objectivity?
Trevor: IF we feel that we can trust ourselves not to write just copies of the SC, that I thinkg it would make sense
Wilco: Making sure the rules are unambiguous is the greatest benefit for the rules
… Making sure we keep that is still the more important part of this
… I am not sure that we need to hold on to objectivity as much as we have been
… After five years we keep working around the problems. Maybe we should accept that and trust themselves enough to write good rules
… We were expecting organizations to write their own rules, but that did not happen
… We are under close control of the rules we write
Trevor: Somewhere in the rules format or the rules writing guide we could put some language to be more objective. It would help to avoid opening the doors to everything