<Dan_Tripp> scribe+ dan_tripp
scribe+ dan_tripp2
scribe+ Dan_Tripp2
<grifare> Present
<Wilco> https://github.com/orgs/act-rules/projects/2
Wilco: glossary page: godwin, we
got feedback from w3c. I pushed back about ~~ putting every
definition into it's own page.
... rather than having everything on one page. I countered that
saying we can put them in summary elements, so the page isn't
massive. and keep it searchable.
shunguo: so they have their glossaries on one page. but they're asking us to do something different?
wilco: they don't do that on WAI
pages. they do it on specs.
... w3c argument is: it's more usable that way.
godwin: can we do both?
wilco: maybe.
shunguo: is there a way to link to both? we don't want two different definitions.
godwin: it's auto-generating so that shouldn't be a problem.
wilco: it's also that one
definition uses another one.
... for a definition page, we could only include the other
definitions that it uses.
godwin: I'm surprised at the
length of many of the pages that I've seen.
... w3c pages in general. they can be massive.
... eg. html specs
wilco: I'm reading this as: they're acknowledging that long pages aren't ideal, and they want to avoid it with new pages.
godwin: is the alleged problem usability for AT or something else?
wilco: it wasn't specifically
mentioned.
... I'm not sure I like having two separate pages.
<grifare> " html specs" looks like an infinite scroll social media page
godwin: will you get something from daniel, or should we follow up directly?
wilco: daniel said he's going to
let me know.
... feel free to add a comment.
... I suggested that if we don't put them on all pages, we lose
the ability to search across definitions. I asked if a
details/summary or similar would be ok.
[ == one page per definition ]
godwin: what's the concern with details/summary?
wilco: I don't know.
godwin: I'll follow up with a more detailed comment.
wilco: next project: reflow rules
from helen.
... there's a PR now. godwin volunteered to review this.
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/2429
giacomo: I can help maybe.
... because I have some context.
... I think the applicability is wrong, so maybe let's start
from there.
wilco: next project: shunguo: aria 1.3.
shunguo: last meeting we had some
discussions, pretty much consensus. consensus is: we should do
one thing at a time. not the whole thing all at once.
... one question: is this the time to do it? because it's still
in draft stage.
... second question: use labels? so we know it's a group of
labels related to aria 1.3.
... epic as opposed to labels.
wilco: use sub-issues. use 2400 as the epic, put sub-issues under it.
shunguo: so for each sub-issue we can make a PR?
wilco: yes.
... then put those PRs not towards the main branch, but rather
towards a feature branch for aria 1.3.
shunguo: timing?
wilco: now.
... we can decide when the merge that feature branch when aria
1.3 goes to "rec". but we should do the work now.
... do we have the individual issues broken out yet?
shunguo: not yet.
... godwin had something. we have 5 open issues.
godwin: do we know what our plan is for flipping from aria 1.2 to 1.3?
wilco: I propose that we create a feature branch then only do the migration once everything is ready. I don't want to be in a state where we have some rules on aria 1.3 and some on 1.2. that would get messy.
godwin: would we be okay with flipping it while aria 1.3 is still in draft?
wilco: we should send it to the ARIA WG. then once they're okay with it, we merge.
shunguo: feature branch might cause issue. say it lasts 3-4 months. then it might have a lot of merge conflicts.
wilco: it could, but we don't change things that often. I don't expect a problem.
godwin: probably won't be a problem. it's text. not spaghetti code.
wilco: when we migrated from aria 1.1 to 1.2 we changed the requirements but we didn't put in any failure examples. so anyone who is testing with 1.2 is not going to have an inconsistent implementation. so nothing passed today, failed tomorrow.
shunguo: to me it looks like an
ACT versioning issue. for example, it might fail in 1.3 and
okay in 1.2.
... there is no way for a specific example to be 1.3 or
1.2.
... if we want to be backward-compatible, we need versions.
giacomo: I agree with shunguo. eg. if we're testing for allowed attributes, and most of our test cases are working, there are scenarios where aria is not backwards compatible, and we'll need to change our examples. eg. back when aria-label was allowed on generic elements, and then it wasn't.
godwin: I'm not sure about having versions. especially with 1.3 going into being a living standard. we could have something like html: a deprecated example.
wilco: things like
aria-dropeffect was deprecated. when it comes to wcag, those
things aren't generally problematic for accessibility.
... I think we should allow these rules to be backward
compatible.
... eg. even if aria 1.3 says you fail, the rule should allow
you to pass.
... not a hard rule. but I think that if we're going to start
failing something, we need a really good reason.
shunguo: that's a little contradictory to what we want to do. we will have some examples that fail aria 1.3, and should fail the rule.
giacomo: yes, now we are
restricting the possibilities.
... so now you can have an empty element where in the past it
wasn't allowed. say we are failing an empty list. because it
required listitem children. now say aria 1.3 says it's not a
failure. so we can't be backward-compatible.
wilco: no if it passes aria 1.3 it should pass the rules. if it passed aria 1.2 then fails aria 1.3 we shouldn't necessarily make that an act rule failure.
shunguo: for each rule, if it
passed 1.2 fails 1.3, we'll have to decide: do we want to
update this example or not?
... we'll have a decision to make each time.
... also we'll have to move the links to 1.3. but now b/c we
want to support both, there's no reason to update these links
any more. also there is no reason to update these 1.2 examples
any more. only thing we can do is: add more examples, what
should be passing 1.3, and what should be passing 1.2.
giacomo: I don't think we have any passed examples that will fail in 1.3. so if we find one, then we can make that decision, based on that concrete example.
godwin: why don't shunguo take
this, and see where it starts to break.
... [ * shunguo and I ]
... it's good for us to be explicit. and not just add an
example. because people might end up asking us whether we're
missing things.
... but let's see where it fails first.
wilco: sound reasonable.
... *sounds
... in some of the rules we've left comments on older aria
versions.
shunguo: eg. combobox
... it's a good point. let's see what happens.
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/2400
wilco: this is mostly just a reminder that the registration for TPAC is open.
<Wilco> https://www.w3.org/news-events/tpac/2026/
wilco: I'll be there, jenn chadwick, giacomo, helen, dan tripp.
godwin: remotely probably.
<Wilco> https://github.com/act-rules/act-rules.github.io/wiki/TPAC-2026-agenda
wilco: I know we've got a half
day on tuesday and a full day friday. i'll be updating the act
agenda page probably on monday.
... on friday we'll be meeting with wcag 2 backlog TF.
regarding consistency between the two groups.
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/2425
wilco: given the limited time in this meeting, armagan do you have anything you would like to share or discuss? eg. my comments?
<grifare> Heading is relevant and meaningful
armagan: I attempted to stick to the existing format but apparently I was not successful. but first of all, the title: "heading is relevant and meaningful", does everyone agree that that's better than "heading is descriptive"?
wilco: I think we want to have a
title that describes what we're trying to do with this rule. I
think that what the rule is doing right now (and what we want
to stick with) is that the expectation is that the heading is
relevant to the content.
... I don't know that we need the heading to be meaningful if
it's relevant.
armagan: on a passport renewal page, is an h1 that says "hi" a pass?
wilco: no.
armagan: how about a backend code error message, fatal error etc., that's not meaningful.
wilco: if it's above a details description of the error, then I think that it's relevant and I would pass that.
armagan: no, the page is
something else.
... you can make them all irrelevant.
giacomo: the word "relevant" is ambiguous. it brings up the question: do you need a heading? not just verify whether the label of the heading is appropriate.
armagan: doesn't the word
relevant expand the scope of this?
... can we replace "descriptive" with "relevant"?
giacomo: IMO we need two different rules: one is: is the role of heading appropriate? (this covers the relevant part). two is: is it meaningful? (of course you need the context.)
wilco: I do consider those to be
two separate failures.
... fix for one failure is: remove the heading markup. fix for
other failure is: change the text.
armagan: wilco let's meet one on one.
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: Dan_Tripp, Godwin, giacomo-petri, Wilco Present: Dan_Tripp, Godwin, giacomo-petri, Wilco, Dan_Tripp2 No ScribeNick specified. Guessing ScribeNick: Dan_Tripp2 Inferring Scribes: Dan_Tripp2 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]