<Jean-Yves> scribe: Helen_
Jean-Yves: Need to amend the
title to be more meaningful, and not need a new PR
... I just did something for adding the "logo" description to
images in the examples
Jean-Yves: For me things are
progressing, I just need reviews
... #1861 image button with an empty alt - you are in
discussion with the TF for it Giacomo?
Giacomo-Petri: I have approvals but there are inconsistencies between browsers and I am waiting for responses
Jean-Yves: Good
Wilco: I should unassign some of
these as have a lot
... some are in progress and some are not
... we are doing the ARIA 1.2 items but we are doing it in a
batch?
Jean-Yves: I am asking the ARIA 1.2 WG for clarification
Helen: I will have a look and claim 1 bug
Wilco: 5 more rules that are
going to AG-WG - potentially 6
... I opened a PR to add secondary requirements to rules to
address issues to allow people to choose if they fail AAA or
not
Jean-Yves: I had some questions
on that - I added a comment on the rule Kathy is working on as
I have concerns on that
... and there were questions on where it should map or not - so
we will revisit that
Jean-Yves: This is
happening!!!
... 6th and 7th of October in 1 month, and Helen added details
to the PR: https://github.com/act-rules/act-rules.github.io/issues/1847
... bookings can be made if you want?
Wilco: This seems a bit short notice? Has it been announced?
Jean-Yves: We need to send a mail
out on it and maybe change the date?
... we will check this with Carlos next week
Wilco: We need a sign up form for this!
Helen_: Yes!
Jean-Yves: Dietary needs, and meals etc.
Jean-Yves: a PR was added this
summer due to a bug in FF and NVDA by Wilco
... and we should avoid accessibility support issues as it is a
bug in their tools
... it prevents up from using multiple items, like title is not
used as not well supported
... and it is creating a baseline in our support for browsers
and AT
... this creates more issues if they fix the bug - so then the
rule becomes redundant so should we remove it?
Wilco: I think the issue is less significant than you are suggesting - but if we have something in the support section then we should not have something that contradicts that?
Jean-Yves: We try to not point
fingers in our rules, and then how do we know when we should
check it if it gets fixed?
... We might be using bad practice that technically should work
and limits what we can use in our examples
... it gets difficult to track as currently we do not track
this so much - it is not impacting the rest of the rule
... I feel we need a stronger way to track these
Wilco: In the TF we review rules
annually to make sure we check these
... We actively support it, and we have an issue assigned to me
as a way to support this and to figure out why items are not
supported so well
... the motivation comes from principles of WCAG itself - that
you can only rely on items that is accessibility
supported
... It is up to the tester to decide if it passes or
fails
... it is known it might not fail in some cases, or pass - we
are trying to cover this as otherwise it fails the main WCAG
principles
... like on SVGs using the image role, we are using that as it
fails WCAG due to FF and test methodolgies...
Jean-Yves: Very true - I can see
the point here as it will fail if they test with Firefox
... It is good to know that the TF review the rules every year,
but we do need better documentation on this - but where should
it go?
... It would make it more problematic, but it goes against the
grain
Wilco: We would look at ways to identify these cases, and add notes to the accessibility supports section
Jean-Yves: I know in Alpha we had a way to state if it passes in Chrome but failing in Firefox and we can say the pass/fail rates but we should not be pointing fingers like this
Wilco: I do not want this information in the rule as it is not best practice
Jean-Yves: We could just omit tests for those browsers - but we should have some warning and examples are for the developers to work well
Wilco: I can raise an issue for
this
... in both cases we reduce coverage
Jean-Yves: So we can have notes
on the examples known to fail on some browsers
... so this example - are we going to block this for the rule
format update in 1.1?
... Giacomo - want to share?
Giacomo-Petri: Last time we said we didn't have a strong answer on this, and it was proposed we do not have strong feedback on this and will keep the rule as it is
Jean-Yves: We discussed this last meeting and when we have links with the same name but different context then it is a bad for everyone
Giacomo-Petri: I provided an
example of this for the PR
... When you have a image with a poorly defined name, it will
fail 1.1.1 but if they use the same name they are ambiguous in
general
Helen: Would a link with some context that is hard to work out although it is bad for all worse for some?
Jean-Yves: No - as in the case
Giacomo did, the background image gives context to a sighted
user, but not a screen reader user.
... still not sure what to do with this
... It is programmatic context that is the important part.
Wilco: Is there a concrete question for AG here?
Jean-Yves: I don't think so... I
feel confident of what should pass or fail but not sure if it
is doable in the rule
... Can we do that kind of fix? Is it worth it if not
applicable in life?
... Maybe to the TF but not AG
... We need a proper definition of context here
Wilco: What is not clear here?
Jean-Yves: Well it is not really useful and does it really happen in real life?
Giacomo: If there are 2 links with the same accessible name and different locations it does not fail 2.4.4 but 2.4.9
Jean-Yves: If the name is fine for one but not the other then it is still ok and not failing... but I need to do some research on this
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) Default Present: Helen_, giacomo-petri, Jean-Yves, Wilco_ Present: Helen_, giacomo-petri, Jean-Yves, 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]