<CarlosD> scribe: Helen
Carlos: Going through the PR with one overdue to test merging automated tests and one with 2 weeks to review
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/carlosapaduarte
Carlos: Lots open but some
progress on them. ...: PR 1655 needs reviews
... 1749 I addressed Jean-Yves comments
... 1560 was opened a while ago and I have just finished
updating it and ready to review
... And we will discuss another issue
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/WilcoFiers
Wilco: I am just focused on
automation and I am trying to work on our WAI website pages
...: I am focusing on working examples, and once I
have that I will be in touch with you to move your examples
over too
... Do not replace your current implementation but use a new
URL for any updates
... just getting to the point of completion
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/Jym77
Jean-Yves: I would like some
reviews on the draft PR 1804 where I tried to apply the
solution that solves 2 issues
... there is also showing the share assets in PR 1805 and want
reviews of the changes
... They are only drafts so not officially requested reviews
yet
Wilco: Something for the TF?
Jean-Yves: Please do if you think it is appropriate - but maybe we should start here first and once agreed send it to the TF
Wilco: Ok
Jean-Yves: If we cannot agree,
then yes maybe ask them?
... so please review these and let me know your thoughts on my
solutions as new ground
... rest are to be started
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/daniel-montalvo
Carlos: If no reviews in next 2 weeks we will add them as an agenda item
Daniel: I have a couple, some of
the audio roles from the TF work and changes
... PR 1808 for the one above and 1802 I am just making a few
amends and ready for review
<CarlosD> https://github.com/act-rules/act-rules.github.io/issues/assigned/HelenBurge
Daniel: I am will work on the other later
Helen: Will get to my issues soon
Carlos: Any updates?
Wilco: Nothing too major so I
don't know if we are cleared for a 1.1 update
... I don't doubt it will get accepted.
... We are working on rules we didn't know have been
implemented, and we are doing surveys on them. We are focusing
on media rules as a large batch we can do
Jean-Yves: Any updates from the ARIA group?
Wilco: It is on my list to
do
... We might update the name we are using, we are trying to
revert back to ACT rules in the WAI website, and then we will
have subsets of names according to the area they belong in
Carlos and Daniel +1
Wilco: The AG chairs need to get
time to discuss it though
... we won't lose the label but we need to talk to the ARIA TF
to separate the tests out
... there are a few minor updates to the rule templates on the
WAI website as they have tweaked and they went live
Carlos: It started with some
decision that CG made a while ago
... PR 1790 - last September - non-empty accessible name rule.
Last month I took on the task, and it replaced 5 rules but did
not deprecate all, as 2 are still valid
... Wilco pointed out it creates potential issues with the work
going on for new definitions for consistency
Wilco: This new rule fails links
on 4.1.2 only but not 2.4.4
... a tool or tester might fail 2.4.4 in these cases, and if
the mapping is not right then the rule needs updating
... this is doing the opposite of failing 4.1.2 and not 2.4.4
but if we fail both it will need the tools/testers to fail both
success criteria
Carlos: so the proposal is to
drop the generic rule? And if we agree that can we have a
second proposal to have form controls with a non-empty
accessible name
... Looking at the issue in the TF they requested to split it
into 2
Wilco: It was an idea but not fully agreed or worked out
Carlos: Do we agree to drop the generic rule?
Jean-Yves: We could add an
exception for the ones that do not fail 4.1.2?
... Rather than dropping it as it helps to remove the duplicate
rules
Carlos: If we have exceptions for the image button and link - we would just condense 3 rules not 5
Jean-Yves: Yes
... I can see both sides as several rules allow us to be more
precise per example
... What are the thoughts of everyone?
Wilco: It can be worthwhile to keep them separate as if AG changes what applies to form fields would require us to separate them again
Jean-Yves: Yes but in some cases it requires multiple maintenance updates on example changes
Wilco: I appreciate the work as
gave a useful discussion but I think we should keep them
separate
... do we want to be this strict about the mapping?
Jean-Yves: Do we want to be that
strict? If we get too generic it might over fail SC when not
necessary
... It is complex to set up with lots of exceptions and edge
cases
Wilco: Being strict of 1 rule per
scenario makes it easier to not cause extra work. But it does
ask rule vendors to break it down and ACT does not allow that,
it would be a partial
... TF seems onboard with that
... Getting this done seems a difficult task of how we do
reporting in future though
... Could do an is part of type implementation?
... Will we need a widget for the overarching items when 3
comes in?
Carlos: But that is not likely to be soon?
Wilco: True but I know there will be a risk of a major rewrite if we adopt this approach when WCAG 3 is released
Jean-Yves: Yes the rules will need changing anyway, as these are written for 2 anyway. But we should wait for closer to the finalised version of 3
Carlos: We will have a few years yet
Wilco: Maybe 10 years? And we have to support Countries that use WCAG 2 for legal reasons
Carlos: Are ACT test rules having significant impact on how 3 is being written?
Wilco: Yes, as AG have accepted the ACT rules as the way to write methods, so ACT will no longer be bolted on but central to it.
Jean-Yves: Formats can match, we
only have rules for HTML and SVG, but the format can work for
other code bases
... The rule will need amending anyway, but the format doesn't
change as it works, so the mappings will change and the
conformance level will change as we don't have that
Helen: Do we need to support WCAG 1 at all?
Wilco: No
Jean-Yves: We need to add why we need the exception in the button rule for image buttons so people are not confused as to where it applies
Carlos: Yes and another thing this rule was doing was adding menu item to the items checked
Jean-Yves: We already have that as a new separate rule
Carlos: I will close this PR and update the button rule
Jean-Yves: I set this up as it is
a best practice to have it hidden left rather than top, as
hidden top can cause page jumps when it is focused, and it
might still be visible
... and we have this choice where we can take care of one and
not the other. And we should hide stuff in other ways, we do
not want to change the example for all, as a lot there. We are
missing some implementations
... It is a way to get more rules published, and showcasing the
best practice that might be used by developers
... But I am not sure if this is still the case?
Carlos: Wilco can you check with the TF if we need 3 examples?
Wilco: We are no longer passing
things on to the TF so long as there is at least one
implementation. So the 3 no longer matters
... I have no problem in changing this to be following best
practices as this was brought up by the vendor who tweaked it.
I don't mind them doing that, but it might cause some to look
like favouritism/the rules are not valid as is
Jean-Yves: I think that is a good
point, the heuristic we use is working with the best practice.
If it wasn't the best practice then this would not be
required
... I want to see them implementing our test cases without
needing to adapt the solutions/implementations
... I agree with you Wilco
... the tool should know it is hiding stuff
Daniel: Do we agree that best practices are required for consistency?
Jean-Yves: Do we agree on having examples that must have 1 for left, top and right? Or just use left? As we have a mixture currently
Daniel: For accessible name we wanted all possible ways, but do we need all for visible?
Jean-Yves: We do have a list of
examples for visibility, but maybe not in every rule
(51?)
... We only use position not clipping
... I do not think we must have all the best practices but use
edge cases to push the boundaries, we do not want to have
people to copy our code, as we have tonnes of bad code of what
the acceptable code to use, but can pass
Carlos: It shouldn't all be about best practices but good to have them
Jean-Yves: I think I will close this PR, and add more examples to the invisible content rules.
Wilco: I don't think we should change the test cases to be easier to implement
<Wilco> https://wai-wcag-act-rules.netlify.app/standards-guidelines/act/rules/qt1vmo/proposed/
This is scribe.perl Revision VERSION of 2020-12-31 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/denied/accepted/ Default Present: CarlosD, Jean-Yves, Helen, dmontalvo, Wilco Present: CarlosD, Jean-Yves, Helen, dmontalvo, Wilco Found Scribe: Helen Inferring ScribeNick: Helen 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: 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]