<Wilco> trackbot, start meeting
<Wilco> scribe: John
sakim, take up next
*zakim, take up next
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/553
WF: Jay's been working on validation step in the rules. Example mpm test on circleci.com.
npm
A collection of tests that will run every time we make a pull request
(on gh)
guarantees correct format for the tests.
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/553
Jay's suggestions for additional tests (find in backlog)
(leave ideas for new tests in issue 553 (previous issue))
BB: had suggested adding this, but WF thought to remove it
WF: concern with how someone can know wcag compliance, risk of false false positives
BB: assumption feels like a patchwork solution , but if we want to remove the assumption then we have to have a good description
WF: need something that non experts are able to use
BB: applicability and expectations need to change : test only the things that apply to wcag
WF: not suggesting that we change applicability, but to make better descriptions (549)
CD: agree with wilco
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/549
<Wilco> https://act-rules.github.io/rules/6a7281
WF: a similar rule, aria states
and props being used to comply to wcag
... 2nd assumption in the above link
BB: yes, all of these assumptions should be expanded to state what that means
WF: volunteers ?
JH: can work on this
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/494
WF: so, the claim is that there is no keyboard trap here
<Kasper> Apologies for the delay!
A : well, i don't understand the example
A : JS solution that seems to work .
A : will submit
AM:
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/493
<Wilco> https://act-rules.github.io/rules/2ee8b8
WF: we miss a test case for
writing out numbers
... if the visual text is a number, a numeral, spelled out in
the accessible name, is that going to work ?
BB: can't differentiate between them with voice command software ; but how to test in multi lang situations
CD: even numbers will be read in the language of the SR
WF: if you use the number 2 ,
then it should be the same in the accessible name , as far as
the SC is concerned
... should be the same sequence of characters
CD: agree
WF: who wants to test this with Dragon ?
<crickets>
WF: I will work on this
<audrey> https://www.w3.org/WAI/WCAG21/Understanding/label-in-name#mathematical-expressions-and-formulae
AM: examples of numbers written in letters does not seem to be a problem
CD: but may create issues for translation
WF: two and two should not pass
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/480
KI: it really boils down to :
test cases are good, and we need more, but also that the
current approach does not lend itself to large numbers of test
cases
... large numbers of markdown files would be an issue
WF: is this a real problem
though, so far the test cases we have written are not to verify
that an implementation is bug free
... more about confirming the presence of the higher
level
... more test cases means greater cost (maintenance) . These
are the 2 reasons that we try to keep the test cases down
KI: the point is to cater to the point (for example) of the edge cases ; we comment on the issues, but this seldom makes it into the test case.
to avoid losing what is discussed, and creating test cases based on discussions
WF: but this would not necessarily lead to the number of test cases exploding
KI: there are some rules with 10 to 15 test cases ... so quite high
WF: is the concern the MD file or is it the presentation of it ? with more than 4 it would be good to collapse them down
KI: the problem I see it is more
to do with merge conflicts
... different people adjusting test cases. Example :
<Kasper> https://github.com/act-rules/act-rules.github.io/pull/477
WF: test cases outside of the rules will be a complexification for authours, and create an awful lot of files
KI: true, and dealing with merge conflicts might be preferable to dealing with separate files
WF: so, good point, and the
number of test cases will continue to grow, but it should not
be the visual presentation that governs the number.
... so we should find a way to collapse the test cases , but
keep them in a single file
KI: ok for me
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/564
WF: after a month, it is time to announce the closure of auto-wcag stuff. Thoughts from the group?
CD: has been enough time, people who are involved should be aware of it
WF: will send a notification.... during 2 weeks ?
CD: fair
AM: ok
WF: please take a look at these pull requests
WF: please look at changes
Final thoughts
AM: thanks, great talk, still looking through test cases
BB: a ok
KI: no update on changelog updates , but can find some time
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) Present: Carlos audrey Wilco Kasper Found Scribe: John Inferring ScribeNick: john 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]