scribe+
helen: looked at AT testing discussion. also transcripts / wilco.
<Kathy> scribe: Dan_Tripp
helen: planning what to do next.
kathy: during office hours, worked through open PRs. reviewed a couple.
giacomo: reviews some PRs. talked with wilco during office hours. closed some very old issues that I opened that are covered by newer PRs.
jean-yves: working on other things. couldn't make office hour - regret. saw misunderstanding re: task force / CG meeting. update from wilco?
tom: office hours - changes in ARIA / HTML. affects one of the rules about decorative. about the meeting calendar - hard to find the zoom links. ended up in wrong meeting.
wilco: taking over some work on
media rules. started last week. new meeting schedule: will have
one consistent time when we're running ACT meetings. instead of
one task force meeting per week, will shift TF meetings up one
hour, so they're at the same time as the CG call. alternating
weeks.
... one TF call will be a working session.
... still need to announce via email.
... will start this new format next week.
... if it's just the recorder (michael) can we boot it?
... who is the host? (of this zoom meeting)
rachael: no updates.
sage: attended office hours.
talked with wilco. lost some PRs.
... still trying to get access via github / IRC through
org.
wilco: two things. we need to, as
TF, go over existing approved rules. in the next couple of
weeks. we're a little late. we usually go over them at least
once a year. some of them have been 14 months now.
... second thing: applicability of composite rules. on agenda
for today.
jean-yves: this is something
we've been mentioning. we know that onboarding into ACT is
difficult.
... stuff around github. how we write rules. etc.
... do people feel like we need that call? do we feel that
office hours is taking that role?
wilco: this is one of the functions that office hours should have.
sage: agree
helen: there's a few people that have disappeared. might be worth sending out an email to those people, to see if it might help them. might be why they disappeared.
wilco: could try. people do also (just) leave.
jean-yves: sage?
sage: call last week (office
hours) was helpful.
... walking through processes with wilco. I am pro some sort of
meeting. whether it's office hours or a dedicated call for
onboarding.
jean-yves: problem with dedicated
call is that there is only a small stream of new people.
... and it might feel abstract.
... can we internally promote the office hours being not only a
working session, but also an onboarding opportunity?
helen: I'm proposing not setting
a meeting, but reaching out to people who haven't attended
recently. and advertise office hours.
... and then maybe we create a dedicated meeting if
appropriate.
jean-yves: are we sending a special reminder for the office hours?
wilco: yes. and most of them, I know why they've gone inactive.
kathy: github was the biggest
barrier for those inactive people.
... we started a github guide but we don't have 10% of things
in there.
rachael: considered doing google docs, as a temporary way of working, then moving it in (to github)?
jean-yves: for github problems, office hours would be more helpful than an intro call.
wilco: a google doc would be tricky because there's a lot of interaction that happens in github for reviews.
helen: google docs isn't always
easy if your company hates google.
... it's mostly about making people not scared of making
changes.
... I know that some people who drifted off all had issues with
using github.
jean-yves: we need to repeat the
message: you cannot screw up (the content in git). you're not
going to destroy anything in production. we can always revert
anything.
... it can look scary. the website automation etc. but it's
actually very difficult to destroy something.
... so we need to reiterate that they (new people) are not
going to do any real harm on the website or anything like
that.
<Kathy> the draft GitHub guide: https://docs.google.com/document/d/1VF5LB09CDwtJ9iRFGJuYL4i8atqvBpA8JnYuGMWfcqo/edit#heading=h.161g9adyo3hv
helen: so maybe we should work out the mailing list. and say that we'll be doing some guidance re: github in office hours. and we can do some more in a dedicated session if needed.
jean-yves: we should advertise in office hour: attend for learning github etc.
-q
carlos: I think we recorded some previous "intro to ACT" sessions. we might make them available on the community web page. includes some github info.
jean-yves: my intro to ACT CSUN
talk was not recorded. did it again for nordic accessibility
group - was recorded. maybe we could put that on the community
page.
... nordic recording: yes it was in english.
kathy: are we allowed to use that recording?
jean-yves: will need to check but I assume yes.
carlos: yes I was referring to the dublin meeting approx 2 years ago.
jean-yves: we need to ask daniel if we have a recording of that one.
kathy: I think I have the slides from a presentation by wilco years ago.
jean-yves: if it's intro videos
they can be longer and people can watch them on their own. and
we'll need to check transcripts.
... the one we did in dublin. something was ACT rules,
something was github. so maybe if we have time and skills for
video editing, we can edit them down.
<Wilco> https://docs.google.com/presentation/d/1FBBODsJ5IjDROb5U4bbM9wmliCgU3MbM1ZSXA09lNt8/edit?usp=sharing Found it
jean-yves: this is about zoomed text is not clipped. haven't we reached sortof a conclusion?
jean-yves: this was about composite rule applicability.
wilco: we had a conversation
about a month ago. looking at target size rules. one of the
solutions that jean-yves came up with was: come up with 5-6
atomic rules then put them together in a composite rule.
... i.e. where each consideration is in it's own rule. eg. a
consideration like "does it have sufficient size" or "is size
controlled by user agent" or "is inline".
... some of those seemed to us like things that are
inapplicable. then we had the conversation: how can we do that?
because the rules format doesn't have a mechanism for the
atomic rules in a composite rule doing applicability. only
expectations.
... three options: option 1: use definitions for those things
that are exceptions. eg. definition for "controlled by user
agent", and that definition would be in applicability in both
the composite rule and all the atomic rules. drawback: creates
a scenario where we have an applicability that has some
complexity that is repeated in all of the
atomic rules. will require extra examples.
scribe: option 2: can we use the
applicability in a different way where if an atomic rule says
something is a pass, then.... ?
... it creates an odd scenario where something is a pass in one
rule and inapplicable in another.
... option 3: we can detach applicability from the atomic
rules. so we can say: a composite rule can have applicability
that is different from atomic rules. right now it needs to be
the same applicability between composite and atomic rules. but
if we let that go: then again, it will create extra complexity,
that we'll need to explain in the
rule.
scribe: this added complexity
that we create will make rules harder to understand. will
require more explanation in the rules.
... if the problem is that we need to maintain some duplicate
information, then the better solution is to have some mechanism
when we write rules that helps us not have to copy/paste.
... we don't want multiple ways of doing the same thing.
... so that's what we got to in that conversation. so we
concluded that we'll bring this to CG. and see if anybody is
not okay with going that route.
jean-yves: there's also the thing
that a pass and an inapplicable are essentially the same
thing.
... I like option 2.
... I wonder if we should only allow it if the applicability
referring to another rule. eg. this rule is applicable to
everything that would be a pass.
... this would keep the idea that composite rule only looks at
what other rules are saying.
... option 2 is: have the composite rule's applicability be eg.
"passes atomic rule A or passes atomic rule B".
carlos: some of the implementors
don't distinguish between passes and inapplicable. that will
probably create problems for them. what you were describing is
creating rules that will deal with applicability.
... I don't think we should call those rules.
wilco: rules have a tri-state
output. pass / fail / inapplicable. what does that mean if
we're using that output for applicability? what does it mean
for the "user agent exception" rule to fail, when that rule is
used in the applicability of another rule?
... that's weird. a failure is supposed to mean that there's an
accessibility problem eg. SC isn't met.
... or if you have a rule where there's only a
pass/inapplicable ...
... if we want to move this forward, we need a more clear
proposal. TF didn't think this was the right move.
carlos: wilco, can you open an issue with an explanation of the three options?
wilco: yes
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, Dan_Tripp, Jean-Yves, thbrunet, giacomo-petri, Kathy, Wilco, CarlosD Present: Helen, Dan_Tripp, Jean-Yves, thbrunet, giacomo-petri, Kathy, Wilco, CarlosD Found Scribe: Dan_Tripp Inferring ScribeNick: Dan_Tripp 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]