<scribe> scribe: trevor

ACT Standup

wilco: worked on PR for images contain no text, PR is open for that.

<Wilco> https://github.com/act-rules/act-rules.github.io/pull/1969

<Wilco> https://github.com/act-rules/act-rules.github.io/pull/1973

wilco: second PR is an old rule with an inconsistent example
... then worked on getting a new implementation on board

chris: looking at the survey for transform, want to get with wilco or kathy on that
... a few open issues on rotation, reached out to carlos and mark rodgers and am awaiting approval
... tightening up remaining todos then will close it out

Will_C: looked at the ACT secondary requirements, think its going well but had some readability comments
... no PRs but will review for wilco

kathy: focused mainly on the secondary requirements, but in a few reviews on the PRs

tom: opened an issue regarding auto-complete, having some problems getting a rule to pass on something we consider a failure

<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1967

Helen: been looking at the format for rules, chatting with aaron about table headers work. has been taking out aria and stuff like that

<Wilco> scribe+

<Wilco> Trevor: Split time, looking at secondary requirements.

<Wilco> ... Have a PR on essential text change. I just submitted a new comment. Needs a review from Wilco

November 24th meeting cancelled

wilco: next week will be cancelled due to holiday

Last call for AGWG November 29th

wilco: AG chairs put out a survey with rules we think are ready for review. Hoping to get that in fairly soon
... have 6 rules and 2 that I think are very close
... do we mind sending out a CFC for these rules now even though they are still in call for review
... no objections, will go ahead and put out the CFC

Linters as ACT Implementations

wilco: Yay! :)
... I have been in touch with a linter that includes accessibility rules called ember linter
... all tools we have so far run the rules in the browser. A linter is a static code analysis tool that evaluates the source code and checks for accessibility just using that.
... benefit is that you can test really quickly while developing. Its more constrained, but much quicker feedback cycle.

<Wilco> https://deploy-preview-157--wai-wcag-act-rules.netlify.app/standards-guidelines/act/implementations/#accessibility-linters

wilco: i created a preview for this^^
... got approval from ember template lint to include it in the list
... I want to create a new category and allow linters to skip certain examples
... without running styling or JS they can't evaluate them and why i think they are their own category of implementation.
... is included in the description of linters on the page

trevor: some linters could potentially use the CSS, should we consider that possibility

wilco: It would be tough

trevor: Just wanted to be sure we weren't automatically saying cant tell when it could technically be feasible

wilco: Main point is just making it possible for this category to skip certain examples
... should we make the decision or should the tool do it

helen: Should be left up to the tool
... other tools will have more options

kathy: if we leave it up to the tools, I wonder what differences between linters and would lead to questions
... and would it be a result of cant tell?

wilco: It would be a cant tell. Untested means you cannot have a consistent implementation, cant tell says you know you don't know

<kathy> scribe+

<kathy> trevor: for rules we have partial and consistent, current definitions may not handle can't tell

<kathy> wilco: I think they do

<kathy> trevor: glad to have linters included

chris: just to echo, PA11Y gives the CLI and has a linter mode, I like how we have it segmented out

wilco: I think we should be in control of which test cases linters are allowed to skip or not
... we should have an opinion on some attributes such as "hidden" and we set the ground rules
... should prevent the linters from saying cant tell on things they aren't good at

helen: we should collaborate with our first volunteer (ember)
... if we get more than one, then we could potentially revise it

wilco: hoping that after we publish I can reach out to some other linters

tom: Should we have them expose the checkpoints?

wilco: interesting point, had to scrape the success criteria from the documentation

tom: So there should be some document that maps the error id to the success criteria
... we should make sure future linters know that is an option

RESOLUTION: add ember-template-lint to ACT implementations list as first Accessibility Linter

Revisit secondary requirements

<kathy> https://docs.google.com/document/d/1E93qynXtcBVL3beIeenv_cbovCy_TsB8mjhmFZUJfqk/edit

kathy: wilco and i got together and worked on it more. 4.4 is in the current rules format.
... 4.4.1 is the current outcome mapping section, we are going to change that to conformance requirements and then another section on conformance requirements
... the conditions have not been changed, I just think we should change it to be in bullet format
... the real change to describe the new category is 4.4.1 or secondary requirement. current implementation is you cannot be both a conformance and a secondary requirement
... most of the scenarios are roughly the same. Scenario 2 does have another example now
... example of a rule with a stricter requirement having a less strict requirement as a secondary requirement
... if the enhanced failed, the less strict could still pass

will: suggestion to try and simplify the language in the secondary requirements

kathy: I don't think its quite right, its referring to the bullets in conformance requirements section.

will: could we give those outcomes a name that can be referenced later

kathy: would it be helpful to copy the bullets?

will: I think just naming and referencing the names. We are talking about the conditions for conformance
... would it be possible to have some visual guides? Like a flow chart with the conditions

helen: flow charts are very difficult to make accessible.

kathy: will work on making the references back more clear

wilco: I would like to look at how we are defining these categories now
... i think if we define accessibility requirements mapping and conformance mapping
... secondary requirements become everything that is not a conformance requirement
... if something is an accessibility requirement, it is either a conformance or secondary requirement
... so logically if its not a conformance requirement it must be a secondary requirement
... and the secondary requirement expands so we can include things in the mapping that weren't included before

trevor: think I'm following, i feel like our current definition in secondary requirement, our definition is basically "not a conformance requirement" already

wilco: what if we called it a non-conformance requirement, since it is anything that isn't a conformance requirement

helen: we have the main one, because it is the conformance requirement, then we have the secondary ones that could fail

kathy: could we change the name of accessibility requirement

wilco: prefer not to, to keep it accessibility requirement to make this additive

kathy: non-conformance requirement sounds too much like best practices

wilco: relatively happy where this is, should put it in editors draft

trevor: could we use "default" as the rule, a requirement is "default" until proven to be a conformance requirement?

chris: think we should follow more of if when then to describe it better

<Helen> Editors draft +1

<ChrisLoiselle> +1

+1

<thbrunet> +1

<kathy> +1

<Will_C> +1

wilco: May need to do some wordsmithing but the concepts are relatively strong here
... lets do a PR and make a call for review. we can include the community group on that

RESOLUTION: Put secondary requirements proposal into a PR and send out as call for review