scribe+ dan_tripp

ACT standup

jean-yves: still waiting for review(s) for target size.
... also looking into slides for csun.

dan: label in name PR comments, responses.

giacomo: opened some tickets w/ aria group.

shunguo: reviewed some agenda items. added some comments.

kathy: last TF meeting, went through updates in response to i18n team, about rules format. 1.1 draft.

vartika: ... muted. skip.

wilco: new rule. unclear if he will submit it to ACT. it's about decorative images / informative images marked up as each.

giacomo: problem w/ inapplicable example is: our defn of semantic role. (?) in terms of browser exposure, it's exposed by all as a table not region.
... so we need to set accName.

jean-yves: we can use aria-label, then it will work.
... will it create problems?

giacomo: don't think so.

shunguo: this is an odd situation. valid role for table. it's not in our side. but practically, it might cause issues. for visual users, it's a table. for AT users, this is not a table any more. just a region.

jean-yves: no, region is special, it's in core AAM, if there's no accName, then explicit role is ignored.
... (missed some)

shunguo: it's fine to me. I agree.
... but this is still inapplicable.

jean-yves: currently it's applicable. so yes we should change it.
... also a passed example? but that's not what the rule is testing.

giacomo: I can take this one.
... the problem is that I forgot to link the ticket I opened to the other group. you can have many group as child of menu only if there is an a11y child (missed).
... technically it's passing ARIA. but at that point it might be group, button, link.
... I don't think this is the intent of the specs.
... so enable only menuitems as a11y children of group. this is also supported in the opposite direction. spec says menuitem requires parent ... (missed)
... right now it's conforming w/ aria specs. so I agree w/ an aria ticket for clarification.

wilco: is it a wcag failure?

giacomo: I have created examples somewhere. but I remember that this structure, w/o accName on group, will be announced as ... I don't remember. will have to check. but I don't think it will be announced by screen readers. b/c group will be ignored if it doesn't have accName.

wilco: I think that's the deciding factor for me. is there really an a11y problem here? are screen readers going to get confused?

shunguo: accName on group is optional. not required.
... also group can be nested.

wilco: where does it say groups can be nested?

shunguo: ARIA somewhere.

wilco: yes let's find out where.

jean-yves: ... (missed) in the group role in aria 1.2 it says ... aria 1.3 ... still here. not sure what the context of that sentence is.
... maybe it only refers to _some_ groups?

giacomo: (shared screen)
... (started screen reader)
... (showed a code pen example)

shunguo: if you have accName on that group it might be announced.
... could you add an accName to the group?

giacomo: codepen shows group / menuitem / group
... so if you provide a label screen reader says "item 4"
... also, adding a button ...

wilco: button inside group inside menu is not allowed.

shunguo: agree.

giacomo: looking at aria 1.3, menuitem role requires a11y parent roles menu etc.

wilco: for this I agree w/ you. it's weird. but since the group role says that you can nest groups, I think there's an inconsistency w/ aria. we should raise it w/ them.
... happy to go w/ aria group's decision. but for now it's not clear that it (nesting groups?) is a failure.

jean-yves: agree. seems like nested groups could make sense.
... looks like it's something in aria that needs to be clarified.

wilco: this has not gone through the full review process.

jean-yves: same thing in aria 1.2? no. in aria 1.2 menuitem requires group parent, doesn't say anything about grandparent.
... also something we need to consider b/c we're going for aria 1.2
... based on aria 1.2 this is passed.
... anything to do on our side? or just wait for aria group's answer?

giacomo: agree.

wilco: agree.

giacomo: I think I missed when I reported this problem that it's not valid html. example is: passed example 3 of 'headers attrib refers to cell in same table element'.
... passed ex 3 is using headers and ids. appropriate for a table. but the id can be used only on th elements.
... but we're using them on td elements w/ role (missed).
... so it's wrong.

jean-yves: this might've been clarified in html. but I agree. pointing to a td element is invalid html. so we probably shouldn't have that.

giacomo: browsers / AT might handle it. but it shouldn't be a passed example.

shunguo: agree. we should remove the role. role of cell is implicit.

jean-yves: but should we update the expectation? currently pointing at the cell.
... maybe we should say that it's pointing at a th elements b/c html requires that.

wilco: is there an a11y problem with this?

giacomo: the relationship betweens headers and id is html-dependent. so if you have a label associated w/ an input, and you replace the input with a div, does it work? no.
... b/c they're html-specific.

wilco: but AFAIK this does work. that's why we added it.

giacomo: but are we sure that it works everywhere?

wilco: "everywhere" is hard to say. everywhere we tested it: yes.

shunguo: still a good example.

wilco: testing that I've seen for this is that you need the role here.

shunguo: in latest aria, this role is not valid.

wilco: doesn't matter. we're not checking for valid code. we're checking for if it works on AT..
... if we're worried about people doing, then we could add a note: 'we know this isn't valid aria in html'.

giacomo: I'm just talking about html itself. eg. div associated with input. if AT supports it, are we ok with that?

wilco: eg. when browsers started using placeholder for accName, we updated.
... so browsers do things then specs follow.
... not the other way around. so it's valid for us to do it in that direction (browser to spec).

shunguo: in this example we will trigger another rule: (missed). so this example triggers something else. it's against our atomic-ness.

jean-yves: I don't like putting bad code in a passed example. but if people are doing it, and screen readers are handling it, then it's ok. it's still failing other rules. and html validation.
... it's still an author error. but does not create a wcag problem.
... maybe you're saved by the browser / AT. but that's ok b/c the user is not impacted. I'd be up for adding some description saying "this is bad, please don't do it".
... but don't fail it for 1.3.1. this rule is for 1.3.1.

giacomo: I think that it works b/c if you remove the id and the headers, it's the same. headers and id attrib are not working here.
... relationship is provided by semantics of the table. if it's working w/ headers and id attribute, it's b/c it's working without them also.,

jean-yves: if we swap the id, will screen reader announce swapped header for the table?
... if we pointed headers to other column - which is bad - does it work?

wilco: I think that's worth testing.
... if this shows that you can make this work w/o headers / id. ....
... do you get default semantics as fallback if headers points to invalid IDs? don't think so. but worth testing.

giacomo: I replaced header2 with header1. still associated: first w/ first, and second w/ second.

wilco: doesn't voiceover ignore headers attrib anyway?

jean-yves: are we saying we need more tests?

wilco: yes.

jean-yves: header is overriding the situation and we don't default (missed). that's what failed example 1 is testing. so we should keep that in the test and make sure it's still failing.

shunguo: when this test only fails one rule. it passed this rule but it fails another rule. ...?

jean-yves: this is part of our test case design.
... as much as we can, the test case should only fail one rule, but it's not always possible.
... we'll need to say "this is bad, please don't do it" in some cases.

giacomo: agree if we swap it and it works everywhere.

jean-yves: if voiceover is ignoring an attribute, shouldn't we have an a11y support note?
... that this rule doesn't apply everywhere?
... alright, conclusion is to do more tests? everything is on you, giacomo.

giacomo: maybe I can do it. question is: the test should be: we swap the two headers' values and see if the proper header is announced?

shunguo: what can that test tell us?
... if you swap these headers, is it an a11y issue? or just html issue?

jean-yves: that will be a 1.3.1 failure b/c the visual presentation is not what is transmitted [to AT].
... so: does AT follow headers even when it points to a td element?

shunguo: passed example 4: points to td. also a good example.

jean-yves: in passed ex 4 we need the headers attribute to go through the intermediate header and refer to both header and the second.
... but maybe if we see that headers attrib is also working on td, maybe we need to make ..... (missed)

giacomo: james asked for the applicability to list how browsers use heuristics to remediate elements that aren't working as expected.
... tables are complex. even if we are able to say: this example is working with browser / AT XYZ, maybe if the table becomes more complex, it won't work. they readers will assume that it will work in a more complex table.
... I'm not confident that we can keep it based on a simple test.

shunguo: more generic question: does ACT rule depend on the browser behaviour to make its determination?
... when there is a conflict, browser has to try to resolve.
... our rule is to report the root cause of the conflict, rather than depending on browser's behaviour.

jean-yves: that depends on the rule. connected to earlier discussion. wcag doesn't depend on browser. but wcag fails if something isn't presented correctly to users. eg. sc 4.1.1 - used to be a problem. nowadays it isn't.
... so that SC was removed. you can still make invalid html as much as you want. but the browsers are going to turn it into something ok.
... when we have rule that checks aria: if aria says so, it doesn't matter much what the browser is doing. but when we have a rule that checks for eg. 1.3.1, if there's no problem b/c of browser / AT, then it's not a 1.3.1 failure.
... so it sortof depends on what the browser does.
... when we check for WCAG SCs, we need to check that it's actually at problem for at least some users.

wilco: can we take a pragmatic approach here?
... (focus on real user problem)

giacomo: but then it doesn't matter if we swap the values, right? if headers and ids don't work, then it doesn't matter. it's working b/c the structured of the table is working.

wilco: if you swap out the rows, that should prove it, and that should not cause the 1.3.1 issue.

jean-yves: maybe that's what we can do. put headers at the bottom and style it.

kathy: I just tried swapping headers attributes, and JAWS is still reading it correctly.

jean-yves: "correctly" means following headers attribute?

kathy: "15%" is still having the "projects" header.
... so it seems like it's using the role=columnheader

jean-yves: so it seems to be ignoring the headers attribute.
... if pointing to td element.
... so maybe we should updated expectation: say it needs to point to a th element.

shunguo: original issue to me is: not that this example is a bad example. if our test case is passing this rule and failing another one.
... for passed examples, don't fail another rule. that's the best case to me.

jean-yves: but how could we do this without failing (AKA triggering) another rule?
... if these are headers and they don't have a role of columnheader, then it's a failure of 1.3.1.

shunguo: disagree.
... there's an implicit role of cell. so we don't need it.
... other than that, it's a perfect example.

kathy: I think 1.3.1 to identify headers and table would also be structured.

giacomo: so if you swap header1 and header2, jaws is still following table structure and not headers / id attributes?

kathy: yes, so, in the cells for "15%" and "10%", I changed the "15%" to headers="header2", and jaws was still reading "projects". so it was reading it correctly even though I had the wrong headers attribute.

giacomo: so there is no value in passed example 3.

jean-yves: if the header is not followed on a td element then we should not accept it in the rule.
... we need to make sure that this works everywhere. if it doesn't, then we need an a11y support note.
... let's do some tests and discuss next meeting.

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, Kathy, giacomo-petri, Jean-Yves, Jeremy
Present: Dan_Tripp, Kathy, giacomo-petri, Jean-Yves, Jeremy
No ScribeNick specified.  Guessing ScribeNick: Dan_Tripp
Inferring Scribes: 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.)