<CarlosD> scribe: Daniel
Carlos: We just merged the one we
had for 1 week
... for 2 weeks, that ends tomorrow. You still have 24
hours
Carlos: I have been moving some
of mine, and also waiting for reviews on some
... PR 1765
... UPdating the "programmaticallyu determined"
definition
... Also updating the audio and video rules which are going to
become atomic
... I have also addressed requests from Wiclo in other
... 1794 has already been reviewed
<Wilco> https://act-rules.github.io/implementation/equal-access-accessibility-checker
Wilco: A little bit more work on
the CG website
... Added IBM to our implementation tracker
... changes to support the markdown they have in their
implementation descriptions
<Wilco> https://act-implementor.netlify.app/#/
Wilco: Other thing I am working
on is the implementation tracker
... The puprpose of this tool is to make it easier particularly
for manual implementations to include their data
... They can start from a new implementation of you can just
copy paste some JSON data, or import that from a URL
[Wilco demos the tool]
Wilco: Once you include your implementations you can export them. That gives you a JSON file
Carlos: Thank you for this work Wilco
Wilco: I have been doing this, Kathy is doing some testing this week
Carlos: She has already submitted an implementation
Wilco: Did not know that
... One of our bottlenecks is that we don't have enough
implementations for AGWG to approve our rules
Jean-Yves: Merged a couple of PRs, did not have time for more
<CarlosD> https://github.com/act-rules/act-rules.github.io/pull/1802
https://github.com/w3c/wcag/issues/2236
Helen: I assigned this to myself now
Wilco: Work on ACT Rules format
1.1. We are taking a proposal to AGWG Chairs
... We have two new editors for that, Kathy and Trevor
... They will be working on it instead of the previous ones
Jean-Yves: About HTML title
attributes. Should that be part of the link text?
... Seems to have poor support
... Carlos made some test that suggests the title should be
part of the context
Carlos: I think that is probably
the best way to address this
... I did this with just one screen reader, others have done
this with multiple screen readers
... Every browser screen reader combination except for some old
browser versions they all handle title
... But they use it to create the accessible description
... I guess that aligns with what you said, JEan-Yves
Daniel: Would support considering title only for description
Wilco: Not sure why this is a change
Jean-Yves: I don't see the title attribute in the definition, maybe we need to change that to take the accessible description, and that will include all these cases
Wilco: That makes sense
Carlos: I agree
+1
Carlos: Probably not mentioning title explicitly but accessible description
Wilco: Do we then need to say something about the support for aria-description?
<Wilco> https://w3c.github.io/aria/#aria-description
Carlos: Yes, I guess that is a good idea. Although I am not familiar with how well it is support
<Wilco> https://a11ysupport.io/tech/aria/aria-description_attribute
Wilco: It seems it is reasonably well supported
Carlos: I think it makes sense to have an accessibility support note, not just for aria-description but also for title
Jean-Yves: I think it makes sense, it matches the intention of aria-description and we should mention that some will not consider every way you can do it and you may end up having slightly different results
Carlos: I will take care of this
[Carlos updates issue with resolution]
Wilco: Determining if an event causes a change is something we cannot determine unambiguously
Carlos: We cannot be objectively certain about the event that caused the change
Jean-Yves: I agree it may be not satisfying the requirement
Wilco: It is not obvious to me
how I would prove this
... How can I know that an event does not trigger any
changes
... Even if I fire that event, there might be circumstances
that I cannot determine
Jean-Yves: I agree. I feel we have the same problem in the PR about focus and focusable definition
Wilco: What is different is that
we don't say anything about how to trigger those events
... I am less worried about the other case
Jean-Yves: When we link to events
in the HTML spec it is about one precise occurrence of firing
an event
... I think we had discussions that it is only about the actual
occurrence of the event, that's how we made it testable
Carlos: ACT Rules format does not
require this to be objective. That is one of the reasons we
moved this to the expectations
... But by not specifying how to fire this events we are making
it ambiguous
... We don't even mention how to fire the event. We just say
"for each registered event"
Jean-Yves: The "changes in content" definition talks about firing events
Wilco: Do we have other rules like on hover things?
Carlos: Not sure if we have these published, we do have some PRs
Wilco: Did we never complete the "content on hover has focus" rule?
Carlos: No, it still has changes
requested
... We took a similar approach: firing the event and waiting
for 500 miliseconds
Wilco: I am not sure what to do with this one. I wouldn't mind if we park it and revisit sometime in the future
Carlos: It makes sense
Jean-Yves: I think we have the same with the "device motion" rule
Carlos: yes
... I guess we have the same issue
Wilco: I am suggesting that we
leave this open, which means these rules would not be approved
by AGWG
... These are things we want to work on for ACT Rules 1.1
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/reqeusts/requests/ Succeeded: s/\Carlos/Carlos/ Succeeded: s/twhat/what/ Succeeded: s/by no specifying/by not specifying/ Succeeded: s/NO, it/No, it/ Succeeded: s/we live this open/we leave this open/ Default Present: Jean-Yves, CarlosD, Helen, Daniel, Wilco, Akhil Present: Jean-Yves, CarlosD, Helen, Daniel, Wilco, Akhil No ScribeNick specified. Guessing ScribeNick: dmontalvo Found Scribe: Daniel 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]