<Susan_H> thanks!
<scribe> scribe: shadi
<Danielli> can you please confirm password from 10:03, I still can't log into zoom.
Wilco: new rule on menu items with non-empty accessible name
<Danielli> Thank you the new zoom link works!
Wilco: second rule due
today
... suggestion left by Aron
Aron: still thinking about your response
Wilco: please let me know,
otherwise can merge
... issue from Jean-Yves
... good catch on line height
[Wilco explains "Final Calls" are things nearly done, asking for final input]
Wilco: co-chair of this
group
... work for Deque
Danielli: work in quality
assurance
... want to learn more and get more involved
Susan: accessibility
specialist
... happy to be involved again with W3C
Carlos: computer science
professor
... co-chair of this group
... testing engine QualWeb
Aron: work from UK
... also joined to learn and get involved
Jean-Yves: work for
Siteimprove
... previously computer science professor
Shadi: W3C staff contact for this group
Wilco: scrollable elements almost
ready
... role attributes?
Jean-Yves: on the call later today
Aron: auto-complete needs
work
... didn't see anything in the issue
Shadi: on me to provide that, will do and ping you
Wilco: need to check with Helen on states & properties
Wilco: Jey suggesting migration
to typescript
... what do people think?
Jean-Yves: +1
Carlos: +1
Susan: who is maintaining the website?
Wilco: mainly Jey
... some from me and Hidde as well
Shadi: Hidde working on light
information redesign
... great to have input from new comers in particular on how to
improve the information for new comers
Jean-Yves: ideally want to check
color in all widget states
... first idea was to use CSS selector
Jean-Yves: but that does not cover situation when using purely JavaScript
Wilco: so look at CSS style associated with different states and test these?
Jean-Yves: not entirely, tool
could look at CSS or pseudo-class
... inline link rule is somewhat similar
... start by checking CSS, and if not then ask the user some
questions
... could be implemented in different ways
Wilco: do you get the component
in different states and test it
... vs changing the state of the component to test these
... figuring out the different states often feels like a
separate task from the test
Carlos: so remove the mention of states from the rule?
Wilco: wondering about that
Jean-Yves: good question
Carlos: so do we have a rule that
says need to test the link in different states
... or rule saying you need to test a link
... and you test that in the different states
Wilco: the link rule tests
different states
... there is a Technique that relates to it
... which seems to suggesting needing to test different
states
... another related rule on error messages
... initially started by trying to trigger error messages
... but that got super-complicated on how to trigger error
messages
... was boiled down to "if this page shows an error, then check
this"
Emma: good way of deferring to
the people doing the test tools
... which is fine
Carlos: so would separate the link rule into multiple?
Emma: think there is a difference between pseudo-states and widgets
+1 to Emma
Wilco: could have separate section explaining what the rule applies to
Carlos: could imagine something this in this direction
Jean-Yves: can see this working
for certain class of rules
... like links and such
... but difficult for others
... will also make test cases extremely long
... or test cases will be incomplete
Emma: could focus and hover be part of the applicability?
Jean-Yves: tried selection of
classes
... in that example found 18 combinations
Emma: all pseudo-classes relevant?
Jean-Yves: no but also reducing them leaves a super-long list of combination
Emma: only the particular classes that are specifically relevant
Shadi: like the direction Emma is
taking
... usually only 2-3 states may be specifically relevant
Wilco: generally want to keep the
rules atomic
... suggesting not to include states unless specifically
relevant to the test
... putting information in the background could work for
now
... and record thoughts about future improvement to the Rules
Format spec
Aron: could also separate into different rules
Wilco: think limitation in the
rules format
... suggest to go with the simplest approach for now
<Susan_H> I need to drop for another meeting
Wilco: and take this as a separate topic for a joint meeting with the Task Force
Carlos: agree, was thinking in that direction
Jean-Yves: agree too but wondering what to do for this specific color rule
Wilco: don't think we can put different states
This is scribe.perl Revision of Date 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/Jey: suggesting migration to typescript// Succeeded: s/widgetsd/widgets/ Default Present: Wilco__, Carlos, shadi, Susan_H, EmmaJ_PR Present: Wilco__ Carlos shadi Susan_H EmmaJ_PR Found Scribe: shadi Inferring ScribeNick: shadi 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]