<LionelW> Zoom Passcode?
<anne_thyme> Could anyone tell me the password for zoom? :)
e
<scribe> scribe: dmontalvo
Wilco: Bunch of final calls going
on. WAI-Tools is ending, wrapping up things.
... Role attribute rule is updated, now maps to 1.3.1
... Meta element has been updated
... Iframe with negative tabindex I have updated as well.
Wilco: I think these are going to
get merged by tomorrow. If you have feedback, share it
today!
... 2week: Image file one is deprecated
... Link name alone is descriptive (AAA), meta refresh is not
delayed, color contrast enhanced (AAA)
... maybe AAA not high priority, but they do feel a gap
Carlos: Image contains no text -- hopefully we've cought everything
Wilco: Bypass blocks is also in final call
Wilco: Things with changes requested
Carlos: I updated the list
yesterday
... Object element is missing, needs to be moved to "changes
requested"
Wilco: Some things have come
back, we need to figure out how to handle those
... Jean-Yves did the image one
... Meta element I will pick it up
Aron: I can pick up all table headers have assigned data cells
Wilco: Helen, let's talk about the meta element one
<LionelW> Can you share Slack joining info again?
Carlos: How do people join slack?
Wilco: We updated the website with this info
<Wilco> https://act-rules.github.io/pages/contribute/join/#join-us-on-slack
Wilco: I encourage everybody to
join the W3C community space on slack
... Helen, we need to look at the accessible name one again
Aron: Headers attribute refers to table cells in the same table -- I submitted it to the TF (503)
Wilco: Samira is still working in the menu one
Carlos: Element with aria-hidden
has no focusable content (1444) -- I took another pass, people
can have another look
... Didn't get to the TF yet. We still need three approvals in
the CG
<Wilco> https://act-rules.github.io/rules/80f0bf
<Wilco> https://act-rules.github.io/rules/aaa1bf
Carlos: The rule applies to
elements that are not mutted, and a duration of more than 3
seconds. We have an applicability that the media resou8rce must
be longer than 3 secs, and an expectation that the audio lasts
more than 3 seconds.
... We can rewrite the applicability and move the expectation
to the applicability, so we won't need the atomic rule
... or we can remove the 3 seconds condition, and keep the two
rules
Helen: think we should remove the 3 seconds condition. How could automate the length of it? Would be complex
Carlos: I think we don't have options to remove the 3 seconds condition
Wilco: It seems we thought it was necessary, then we refactored it so that it was not but never updated it.
Anne: Maybe we thought some of it could be automated and some of it could not, this is why we have the two rules
Aron: I think this would be more understandable if there were two atomic rules. One for a mechanisms to, and the second that the audio doesn't liasts for more than three secondspause and stop.
Carlos: I think that the suggestion is that we rewrite the applicability so that it only aplies to audio that lastst more than 3 seconds
Wilco: The expectation of the second atomic is unambiguous, so that could be part of the applicability.
Anne: Yes, but you should be able to find the applicable elements using automation. IF we put it into the application, I don't think therere is a tool for that.
Wilco: There may be, but you'd have to analyze the audio
Carlos: We could do it with some video formats.
Anne: You could have an audio track that lasts an hour but with a lot of silence on it
Lionel: Also sound sometimes is "decorative" Should we make this clearer?
Wilco: I think the SC does.
... Sounds that anybody is opposed to making this one single
rule.
Anne: Maybe we need to check with implementors
Carlos: In the composite and the atomic you have QualWeb
Anne: If we create the applicability so that it cannot be automated, will we have implementations?
Wilco: From the implementation results, seems they now how to do it.
Carlos: They are missing the inapplicable, though.
Wilco: I agree, let's see what Kasper thinks.
Carlos: I can take it, let me check with Kasper
Wilco: Also should check with Mark
Jean-Yves: Instrument is our
definition of WCAG's mechanism. We start by saying the
instrument needed to be part of the accessibility tree, but we
were pointed that that was not part of the SC.
... But the mechanism definition does have a note that they
need to meet all SCs at the level you claim
<Wilco> https://www.w3.org/TR/WCAG21/#dfn-mechanism
Jean-Yves: Do we want to enforce this condition or not at all?
Wilco: JThis is strange, beccause the mechanism maybe is not even on the web.
Jean-Yves: Agree that this is not strictly needed
Wilco: This puts a requirement that something meets WCAG. A mechanism is not a webpage, so it cannot meet a SC
Emma: But it can be inaccessible
Wilco: But that's not what the note has
Carlos: Shall we reach the AGWG to correct this?
Wilco: What do people think?
Daniel: I do think we need some reassurance that the mechanism is accessible.
Lionel: Is there some wording about how the mechanism affects the website?
<LionelW> This wording is in the recommended guideline, "an accessibility-supported mechanism"
Aron: I thought the purpose of this note was to refer to mobile apps. None of the rules that I have reaad so far applies to mobile apps
Wilco: I think we can have a similar note on our definition.
Emma: The instrument needs to have the same level of accessibility than the object it is affecting.
Wilco: If this affects to assistive technologies, does a screen reader need to be accessible for somebody who can't hear?
Aron: If we rely on web content only to meet the conditions of the SC, then the definition is clear because it is an HTML element used to achieve an objective.
Wilco: That's why I am suggesting to add a definition.
Carlos: I do agree with Daniel
that we should try to reassure that the instrument is
accessible. The audio and video rules have an expectation that
it needs to be visible and on the accessibility tree.
... I don't think we need to do this for all the rules, but
rather includ it in the definition.
Daniel: I think the note would adress that, as the instrument is part of the website.
Emma: According to what I am reading form the WCAG definition, "We are not dictating how the AT should behave, but we are saying we should rely on it".
Lionel: Volume buttons, would it be mechanisms or instruments?
Wilco: They would be mechanisms,
as they are not part of the webpage.
... if it is a keyboard issue, you would fail that under two
SC, not just for keyboard, but also on the auto-play. Is that
what we intend?
Aron: Yes.
Wilco: That is why it would be an assumption.
We would need to revisit this one next time.
s/Topic: Final Thoughts//
<EmmaJPR> +present
<EmmaJPR> one of them
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) FAILED: s/Topic: Final Thoughts// Default Present: CarlosD, HelenB, LionelW, Wilco, anne_thyme, Daniel, shadi, Jean-Yves, present, EmmaJPR Present: CarlosD, HelenB, LionelW, Wilco, anne_thyme, Daniel, shadi, Jean-Yves, present, EmmaJPR Found Scribe: dmontalvo Inferring ScribeNick: dmontalvo 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]