<scribe> scribe: Kasper
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/607
Wilco: Let's go over this at a
high level, need this merged today.
... Couple of comments from Anne, two abouts which sections to
link to in ARIA and two about the rule itself, which I suggest
we open up as separate issues.
... The references where we link to ARIA are probably worth a
discussion.
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/607/files
<Wilco> https://www.w3.org/TR/wai-aria-1.1/#host_general_attrs
Wilco: If you look at the files, you'll see a new `aria11` accessibility requirement with an ID to a section in ARIA.
Anne: The section being linked to is about host languages.
Wilco: The problem I found was
that the requirements are all over the place and we only have
the headings to link to.
... This was the closest I could find.
Anne: If I can find something else to link to after this meeting, could I send that to you?
Wilco: Sure.
John: Did anybody see the pull requests I've opened?
Wilco: Do you have a link?
John: I'll look for one.
Wilco: It's harder to link to specific requirements in ARIA so maybe we need to revisit this as well. Other than that, do you think there are any major concerns, Anne?
Anne: Not sure, there are a lot of comments.
Wilco: Could you get back to me
on Slack after the meeting then? Does anybody else have
comments to these?
... Moving on to next item.
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/604
Wilco: This is more of an FYI, though I see Anne left a comment on it.
Jey: Just trying to get this done.
<Wilco> https://eloquent-lumiere-13f4f9.netlify.com/pages/implementations/overview/
<Wilco> https://eloquent-lumiere-13f4f9.netlify.com/implementation/access-engine
Wilco: What Jey has done is, which you can see here, is to pull together information about implementations in these reports. The first table shows the tool creator and then links out to a report.
<Wilco> https://eloquent-lumiere-13f4f9.netlify.com/rules/97a4e1
<Wilco> https://eloquent-lumiere-13f4f9.netlify.com/rules/97a4e1#implementation-metrics
Wilco: So at the bottom of each
rule page, there will be a table which implementations there
are of this rule.
... Thoughts, questions, comments?
... Love letters?
Carlos: I was looking and there are some untested ones?
Wilco: Untested means that there
is no data.
... These reports can get out of sync as we update the
rules.
Emma: I'm just catching up with what everyone is up to. Is this the tools doing their own tests and then mapping to test cases in ACT-R?
Wilco: Yes. From the results, we then figure out which things are implemented.
Emma: So this is testing the tools themselves?
Wilco: Is just as much figuring out how much coverage we have.
Anne: Would it make sense to note somewhere the test methodology used? For example, RGAA is manual.
Wilco: Yeah, we want to make that
visible.
... We just haven't built it yet.
... We'll try to merge it this week, so try to get any comments
in today.
Emma: What about the test methodology?
Wilco: We will be adding that as well.
Anne: For the semi-automated rules, how do we expect to create reports for them?
Wilco: You can submit incomplete results, which will tell us when it's semi-automated. Or you can define the test mode in the results.
Anne: From the overview, it currently looks like none of the semi-automated rules have been implemented.
<Wilco> https://eloquent-lumiere-13f4f9.netlify.com/rules/2ee8b8#implementation-metrics
Jey: I think the Alfa report is out of sync.
Emma: The "view report" under implementations, should that link to a specific part of the report? There seems to be an anchor reference, so it looks like it should.
Wilco: Yeah, it does look like it
should.
... We may want to collapse these down to an accordion as
well.
<carlos> https://github.com/act-rules/act-rules.github.io/issues/577
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/577
Wilco: This has been coming for a
while. The intention we've had is that once we have enough
implementations of a rule, we'll start sharing them with the
W3C. The quesiton is, how many implementations should that be?
We initially said a minimum of 3, but it doesn't mean that once
we have 3 we're done.
... The more implementations we have, the less meaningful it
will be to require just 3 implementations.
Shadi: It think the number should be relative to the number of implementations. 3 is a good target, but we need to play it by ear. It could be that 2 tools are representative, and that other tools are looking to implement it. We're really looking for consensus and these numbers could help us. For each one, we'd have to decide whether the rule is really mature.
Wilco: So rather than having a number, we'd have a voting system?
Shadi: Yes, at the end we have to "approve" and "release" rules.
Anne: Would this be when be publish rules or when we send them to W3C?
Shadi: It should be the target
for the working group to approve the rules. W3C should not
publish something unless there's a good amount of consensus
behind it. The more we prepare for that, the less chance that
it will be sent back to us.
... Does that explain what I mean?
Anne: I guess my question is whether it impacts our ability to publish rules on our website?
Shadi: In the past, we said that if there are 3 approvals for a rule, it gets published to the community website and then implementors can start implementing it. We could then list on the website which rules have implementations and list which ones have sent to the W3C.
Wilco: I was hoping we could
avoid another round of voting. We already have the review
process and a CFC before a rule is published.
... What do you think the added value is of having another
decision made on that?
Shadi: Good question. We can try
one of the approaches and see if it needs to be tweaked. Over
time, we're gonna need to approve things. What if there are 3
different tools that use the same engine? Are they really
representative?
... It could just be part of the CFC.
... As we go along, I think we're gonna have to refine the
process.
Wilco: That still leaves open the question of when to go into that vote.
Emma: I think Shadi's point about
the different tools using different engines is a good point. 3
different implementations should be by 3 different
implementors.
... If you have 3 different implementors agree that a rule is
good then I think that is enough.
Anne: I think my concern is that if we put in even more gatekeepers, we'll take the value out of the ones we have. If there's always another time where you can pull the plug on a rule, why even review it? If we put in multiple gatekeepers, people will spread their resources over them and we'll get less value out of them.
Wilco: Yeah, I agree with that.
Shadi: I can see the point. I don't feel too strongly about it, we're still learning and can always refine it.
Wilco: Until we 10 implementors, let's go by 3 implementors per rule and then go to a CFC period. 3 seems like a minimum we'd need anyway. This could be revisited as the number of implementors grows.
*agreement from the group*
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/245
Wilco: I'm wondering whether or not we should continue this one, I'm questioning this myself.
Anne: We talked about this
yesterday and think that this is a valid rule.
... The reason is that if you have a thing a role, you also
give the user some expectations about what you do with that
element. If you something that is communicated as a list but it
doesn't have list items, then it won't behave as a list.
Wilco: The reason we pulled back on this in aXe is because of drag-and-drop widgets that were populated at a later time. I can see the same happening for any kind of element.
Emma: It's possibly not the best user experience to have a completely empty list.
Wilco: It's not a violation of WCAG.
Emma: I would say that having the role on an empty thing is incorrect.
Anne: I don't know how often this happens, but maybe it's something that could be worked around with an assumption.
Emma: I think Anne is right in that it does seem to relate to 1.3.1.
Wilco: I this one we should take to the AGWG?
Anne: What if part of the expectation is that if the element _is_ empty, it must be filled out at a later time?
John: I've seen examples of people makign 5 lists with 1 item instead of 1 list with 5 items because of their CMS not allowing them to properly space the items.
Emma: An empty list would fail HTML validation.
Wilco: Just because it's invalid HTML doesn't mean that it's non-conformant to WCAG.
Shadi: What's the impact on the user? What happens when there's an empty list? Is that an accessibility barrier?
Wilco: I think it can be.
Shadi: Does it get announced?
<JohnH> (The point I was making is that semantic use and correct implementation is not just about empty lists)
Kasper: *outline of some tests that were made*
Wilco: Let's look at the test cases for this rule and proceed with it.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/will/will be/ Present: carlos anne_thyme Wilco Kasper Jean-Yves Moyen Jey Found Scribe: Kasper Inferring ScribeNick: Kasper WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]