Wilco: Item 3
<Wilco> https://github.com/w3c/wcag-act/pull/522/files
Wilco: Example is the most telling of a definition. Using a fictional success criterion, if it is on Level AA, you don't need to list Level AAA, but only A and AA.
Phil: The important thing to ask, who defines the Rule requirements. There should be harmonization. Not sure if this defined in documentation.
Wilco: The Rule definition is part of the rule itself. The rule can be written by anyone and then it is submitted to the AG where it is reviewed. This includes mapping. Anything that the ACT Rules TF publishes needs to be signed off by the AG.
Phil: Mike mentioned hoping to
map to a single success criterion, rather than referring to two
success criteria to one rule. If you don't pass the minimum,
you don't pass the higher level.
... Does the team feel this is problematic? Developers are not
a11y experts, they are asking for solutions. But if I'm mapping
to multiple success criteria, they complain. What I understand
is to take this to AG.
Wilco: How do others feel about that?
Will: I have heard it is confusing for some. Having said that, it's a violation of both so fixing one may not necessarily fix the other. You may only fix part of it.
Wilco: Videos are a really good example. If you have a video that needs a transcript (Level A) but Level AA asks for an audio description, if you only provide a transcript you will never pass AA.
Will: I think it's important to list both.
Karen: Will explained it really well, and the video issue, for me.
Wilco: There may be cases where it's less critical to report a rule under just one success criterion.
Phil: Is there a requirement or is it optional that - for example, at a minimum, the rule reports at "this" success criterion? Acknowledging that it may only be one issue that needs to be fixed. Has there been a discussion about requirement or optional.
Wilco: Something may or may not be a breaking change.
* scribe
Phil: You could have confusion with different tools - if one tool has a different number of checks, and the other has more, but because the tool is referencing more SC. For example, video in Canada, Audio Descriptions (AA) is not adopted by AODA - it's an exemption. The encouragement was to use a transcript with audio description in it - you get "bang for your buck", i.e. both A and AA in one. The rules can help provide direction on what people[CUT]
Will: We should flag all issues and relevant success criteria. If you set the Rule to refer to every single SC that it fails, that's the only way you'll get consistency across tools and platforms. When you start creating hypothetical situations of picking and choosing which SC to refer to, you run the risk of inconsistency.
Jenn: I agree.
Phil: There is a basic assumption that a rule applies to more than one success criteria. There is still debate among experts that it applies to one or more - and that's what we're trying to avoid by setting the rules. If it's not documented, then it could be confusing for practitioners.
Jenn: We may be confusing the audience out there.
Wilco: Conclusion - we all agree that different implementations should report the same issue under the same success criteria. And if we can, reduce the number of Levels that we are reporting on, looking for more areas where we can reduce the number of multiple success criteria.
Will: For example, we can be explicit about certain success criteria, i.e. 4.1.2 Name, Role, Value. If a role is missing, this will always be 4.1.2 clearly.
Wilco: Agree.
Zakim take up Item 1
Wilco: The Community Group is roughly the team writing the rules and this meeting can include community group members. The ACT Task Force gathers, handles the questions about the rules, submits the rules to the AG.
Wilco: Karen, I will ask you about cross-linking.
Karen: I have made a draft.
Wilco: Jean-Yves has recommended
we wait until further feedback.
... Pull request for HTML non empty tag has been merged.
RESOLUTION: Accept updated rules for re-publication.
Will will review the pull request #739
RESOLUTION: Karen and Will to review pull request #739
Wilco: All rules are set to work
with ARIA Authoring Practices 1.1 so we need to update.
... First topic to discuss: Do we want to migrate before the
Candidate Recommendation, or wait?
... Candidate Recommendation is very close, and it's been seen
contributors using 1.2 and beyond. It's possible we may be
falling behind.
... There is interest in tools wanting to utilize 1.2.
Will: If the risk is minimal, I don't see a reason to wait.
Wilco: What do we do with 1.0 and
1.1 support? There are a couple of changes that may cause
breakage; combobox pattern has changed between 1.1. and 1.2 and
some of the attributes have been deprecated. Also, some
elements are not allowed to have an accessible name. The
challenge - do we want to push for the latest standard, ask
organizations to upgrade, and/or allow implementers not to
allow things that were under 1.1 and 1.0.
... "Chair hat off" ... The product I'm responsible for, we
tend to be fairly conservative when taking things out. Things
that exist on the web, we need a good reason to start flagging
it. If something causes an a11y problem, regardless of the
size, we will start flagging it. My rule of thumb. ARIA that is
still widely supported, I feel continuously needs to be allowed
by ACT Rules.
Jenn: I would appreciate Jean-Yves' thoughts and recommendations at Siteimprove, if they align with that.
Wilco: The issue - causing inconsistency.
Will: It's true - this hurts adoption. Companies will build something and have to un-build it. Do we take the same approach as with all the flavours of Internet Explorer? There is a good possibility here in the US that the law may stick to 2.0 or move to 2.1, 3.0.
Wilco: Wrapping up, I feel like this needs a proposal, and a specific one. Will, might you be interested in taking a stab at this?
Will: Sure. Send me the basics.