Wilco: Nothing major; WCAG 2.0 doesn't have inapplicable. Thoughts, comments, concerns?
Shadi: Wondering if it could be slightly rewritten. Could maybe say that "not applicable for ACT rules is a pass according to WCAG".
Wilco: It's not necessarily.
Shadi: What does it then mean to get an inapplicable result if I'm trying to map result to WCAG?
Wilco: That's why I'm pointing to aggregation. I.e. what do the results mean for the success criteria?
Shadi: Don't have a better suggestion right now.
Wilco: <describing context of "inapplicable" results>
<Wilco> "If nothing was applicable for a WCAG 2.0 success criteria, it is considered a pass"
Shadi: Same with techniques; if a failure doesn't trigger for a page, it doesn't mean that the success criteria is passed.
Anne: We cannot say that a success criteria is passed.
Shadi: The way it's written is a little
confusing. We're not introducing something new, just being more
explicit.
... Maybe turn it around and talk about aggregating results first? E.g.
"inapplicable results only rule out that there are no failures"
Anne: Inapplicable is not a term used in WCAG. Seems too specific as you can't have a WCAG success criteria that is inapplicable.
Wilco: Not sure what to do. Do you want to propose a change, Shadi?
Shadi: Let's go with this for now.
Wilco: Should we open an issue?
Shadi: It's resolved. Might need to be put somewhere completely different.
Wilco: Will ping David for further comments, otherwise it's done.
Anthony: This is my second call, joined in before CSUN. Work at Pearson. Have worked with accessibility for about 10 years. Would love to contribute to this work going forward.
<tbostic> Hi I can hear everyone, not sure why mic isn't working :(
Trevor: Focus mainly on software development. Focusing on both using WCAG rules in addition to ACT rules for automated testing.
Wilco: The picture in the pull request
really says it all. Any thoughts?
... AutoWCAG has been working out ways to write test cases that are easy
to write and looks good.
Jey: <sharing screen to present
changes>
... Wilco wanted an automated way to put in an iframe to show the output
of the test case. Implemented a Ruby plugin for Jekyll for doing this.
... <provides explanation of how the plugin is implemented and how to
use it>
... Still some work to do, but things are automated now removing a lot
of overhead.
Wilco: We wanted to simplify how we write
test cases and markdown is just easy. Should be useful for ACT as well.
... This let's us do the minimal we need while still being expressive.
Jey: Trying to see if we can get rid of the
additional tags.
... What we can do is make the tag configurable by the person using the
plugin. Will try to find a smaller tag as well.
Wilco: How to want our test cases? There's a difference between ACT and AutoWCAG, but we should be able to take rules from different organizations. Do we need something more low level like the output format for describing test cases to provide alongside the rule?
Shadi: Not quite sure. There's is an open case about adding additional meta data like used in TCL.
<shadi> https://www.w3.org/WAI/ER/tests/usingTCDL
Shadi: Might need additional data to carry out a test, for example parameters describing the viewport. These are things we've pushed aside. TCL has been worked on and we could use some of that in a JSON file to describe what test files are.
Wilco: Was interested in this approach
because it makes it easy to write new test cases as the barrier to do so
was higher than I wanted it to be.
... They also help demonstrate in an easy to understand way what a rule
is about.
... Wanted to solve that problem first.
... Can take the samples and turn them into a different format.
Shadi: We could start from the front-end and
think about how we want to present them. Or the other way around; start
with the data we need and figure out how to present it.
... Need naming conventions, file structure conventions, meta data
conventions. Could then use this information to make presentations or
include it within the rule itself.
Wilco: What format do we want if we want to accept rules from other organizations?
Shadi: When somebody sends you a test rule,
I'd expect them to send along test cases.
... Test cases could consist of several files; HTML, CSS, images, etc.
Could be sent as zip archive, a pull request, etc. What should be the
conventions for storing these files along side rules? I think we need to
define that.
Wilco: This is related; what do we want from the rules repository? <explaining the rules repository>
<Wilco> https://w3c.github.io/wcag-act-rules/
Wilco: We have started some of this work, see URL.
<Wilco> - Rule groups
<Wilco> - implementation manifests
<Wilco> - What format do we want from rules?
<Wilco> - What format do we want from test cases?
Wilco: What else are we missing?
Shadi: Wondering about technologies. Are all the rules specific to HTML? Might be part of the meta data.
Anne: Also, there's currently a column in the overview where it says "WCAG criteria". Should this be changed to "accessibility requirements"?
Wilco: Not sure. Should we publish things that aren't WCAG criteria?
Anne: At least we try to keep it standards agnostic in the ACT format itself.
Stein Erik: For me it makes more sense to be consistent and call it "accessibility requirements".
Shadi: For now, I think this group will primarily be looking at WCAG requirements.
Wilco: Do we want something like search or filter functionality?
Shadi: Some sorting and filtering functionality might be asked for.
Wilco: Seems fair.
Anne: Maybe it would also be nice to be able to search for a technique and find matching rules.
Wilco: We don't currently list the technologies as everything relates to HTML; no reason for that.
Shadi: It might start to be quite complex.
... Presenting all that without making a huge table might be a
challenge. Could filter out information if needed.
Wilco: We need a glossary don't we?
... Anything else?
... Will start creating issues for this and look at who gets to do what.