<scribe> scribe: CarlosD
Jean-Yves: some very old call for
reviews
... the couple of 2-week calls can be merged by Carlos
... and several 1-week call for reviews that can be merged
also
Jean-Yves: no progress to report
CarlosD: no progress in these issues, been working on the benchmarking tasks
dmontalvo: some progress, need discussion on PR#1802
<Jean-Yves> https://github.com/act-rules/act-rules.github.io/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22
<Jean-Yves> https://github.com/act-rules/act-rules.github.io/issues/932
dmontalvo: ACT implementation metrics are to be published in a short time
<dmontalvo> https://deploy-preview-95--wai-wcag-act-rules.netlify.app/standards-guidelines/act/implementations/
dmontalvo: There are still some wording discussion to ensure that W3C is not perceived as endorsing one tool over another
Jean-Yves: there is a situation
where a video playing without audio, with a transcript
offscreen, that is being flagged by rules that require that
transcript to be visible
... we are wondering if we should require that from a video
that has no audio, because sighted users can see the in the
video the same content of the transcript
CarlosD: the success criteria requires the alternative to be "provided"... we need to decide what "provided" means
Jean-Yves: We have the same situation for SC 1.2.3
CarlosD: The intent of the SC is make information available to all users. The video-only content would be available to sighted users, and the transcript for non-sighted users.
Jean-Yves: Some low vision users
might prefer the transcript, because they might not be able to
perceive the text in the video
... G159 states that the transcript needs to be
programmatically determined. It doesn't state anything about
the visibility.
<dmontalvo> I am OK with this
Jean-Yves: We should change the expectation and add an assumption
Jean-Yves: The issue is raised
because screen readers won't voice these elements
... but Mark found some instances where combinations of screen
reader and browser would voice it
... there is already #1820 that is changing from focusable to
tabbable
Jean-Yves: The inert attribute is
getting support in the recent browser versions
... this attribute takes the element from focus order and the
accessibility tree
... this will impact many rules and we should add examples to
the rules
... there is also the situation caused by the dialog element,
that when open should make other elements inert (without the
inert attribute)
dmontalvo: what is the level of
support for inert from browsers and screen readers?
... I envision several misuses of this
... should we have a rule that checks if inert elements do not
have focusable content?
Jean-Yves: the browser will make inert elements non focusable
CarlosD: We should add inert examples and also examples with dialog
Jean-Yves: We don't need dialog examples in every rule, but we should have coverage for inert at a similar level we have for aria-hidden
Jean-Yves: There will be no meeting in a couple of weeks due to an holiday in many European countries
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/working/wording/ Default Present: Jean-Yves, Daniel, Wilco, CarlosD, ToddL Present: Jean-Yves, Daniel, Wilco, CarlosD, ToddL Found Scribe: CarlosD Inferring ScribeNick: CarlosD 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]