Meeting minutes
ACT stand-up
Jean-Yves: Worked on one of my PRs
Daniel: I've done publication stuff with Remy
… There were some broken links he raised, which we fixed.
… I updated actions we were using for publications. Thank you JY for approvals.
… We've also been thinking about how we can work on implementation data vs approval updates.
Sage: Curious if there's anything yet for the topic we discussed last meeting
giacomo-petri: Some reviews during our last office hours
Wilco: Planning around ACT. I think we're reaching a pivot point for the group. We need to think about things AGWG is asking us to do
… Some of my planning is on the agenda today, some is waiting for Kathy
Shunguo: A couple of reviews
[b49b2e] Accessibility support note on empty headings being exposed — act-rules/act-rules.github.io#2351
Jean-Yves: Recurring question, change to an acc-support note
… giacomo-petri opened an issue and is not happy with this PR
giacomo-petri: First of all there is no agreement on AGWG
… Group is split in half (some think it should fail 2.4.6, others also 1.3.1)
… In our tool we have a manual note for empty headings under 2.4.6, browsers still expose it in the accessibility tree. It's still a heading, even if it's empty
… Stricter requirement of the SC is also not very clear
… Heading is not defined in the glossary, other terms are
… We shouldn't say that an element which browsers expose as heading is not a heading
… I strongly believe we cannot force people not to fail 2.4.6
Wilco: Labels is defined as something that has the function of a label. It isn't programmatic labels
… It identifies another component
… IMO it doesn't make sense at all to put in under 2.4.6
… If you extend the logic of the label definition to the headings, and more specifically to empty headings, it'd be a non descriptive heading, so it wouldn't make sense
giacomo-petri: If a heading is not meaningful then probably shouldn't be a heading
Jean-Yves: In the background we already have notes that we consider headings that are visible but not in the acc tree are failures of 1.3.1
Jean-Yves: The problem is we'd have an accessibility support note and we'd have examples that targets the note specifically, which is problematic
… Also Wilco thinks these examples do not fail 2.4.6
giacomo-petri: We are now focusing on AT (screen readers). What about people using extensions to highlight certain parts of the page, like headings, they'd have empty areas on the page, it's difficult to assess the impact
… The user agent is still exposing the element
Wilco: We've established a principle a while ago that mismatches in the content and the accessibility tree are 1.3.1 issues
… We had a heading rule that checked both the accessible text of the heading and the visible content of the heading
… We stepped away from it because we ended up thinking this is a 1.3.1 issue
… IF we want to revisit that decision there are broader implications
… aria-hidden problems go on 1.3.1. I'd continue with this approach, otherwise we'd have to make broader decisions
giacomo-petri: I'm not saying we should revisit that
… But we are assuming this empty heading shouldn't be there
… Thee authors may forget to enter its value, but there should still be a heading
Jean-Yves: If it wasn't a heading, for instance if it was a link, would it fail 2.4.9 or 1.3.1?
Wilco: s/ or 1.3.1//
Wilco: I don't think we have had this conversation
Kathy: The SC talks about the purpose of the link being ambiguous to users in general
giacomo-petri: Are we now say that empty links shouldn't fail 2.4.4?
Jean-Yves: I'm just pointing out the differences between links and headings
Wilco: The definition of text does require it to be programmatically determined
… 2.4.4 and 2.4.9 are specifically about programmatic
… It makes more sense for me there
… Labels is not programmatically, just things that function as a label
giacomo-petri: Why using headings? Labels include heading in that context, but if the SC specifies heading, then it is a heading
… Half of the rules could be removed because we're not clear if the role is correct
… IF the author defines it as heading we should take it into account
… The problem is if headings is not defined. But even so, we cannot assume that headings or role heading is not included
Wilco: Disagree, without a definition I can only think of them as functioning as heading
Jean-Yves: I'd agree with Wilco. A button is not a button because an author put the role of button. What makes a button is its functionality, that someone can click or press it
Shunguo: If you have a role button and then you have to provide other things then there's something wrong. There are many cases of mismatch between the accessibility tree and content, cannot simply say it's 1.3.1
… in ARIA, for example, role defines functionality
… If you have a component where you define a button with ARIA, you have to provide all functionality
giacomo-petri: If we have an empty button without an accname and the button doesn't behave as a button, it's failing 4.1.2. We may also raise 1.3.1 on the next iteration or something
… Not sure we should be skipping elements intended to be used in a different way
Wilco: The failure is that it shouldn't have been a button, not that it doesn't have an accessible name
… There is something wrong, which is it has that role to begin with
giacomo-petri: What if it's a button and should be a link?
… Let's assume 4.1.2 is only about form controls
… IF we assume that an element can be whatever and we don't take into account its current semantics, then the whole automation approach would fail, as we couldn't really rely on what the author has set
Wilco: That is true, you cannot be 100% sure, you do have to base you assessment on some further judgment
Shunguo: That's right if the role is correct.
Wilco: I am not saying I am right. Agree that this is open to interpretation. What I am saying is that these decisions we took are based on this underlying assumptions of ACT Rules
Shunguo: If something has a specific SC like 2.4.6 or 2.4.4 then we should pay attention to what's there, otherwise we should use a more generic rule
… Let's imagine you report a missing link or heading, which is easy to spot by the user. But there are other cases where this is more complicated
Jean-Yves: We do have a rule for heading having a non-empty accessible name, but only fails ARIA. Should that fail 1.3.1 as well?
… Then we could flag empty headings as something more serious
Shunguo: Not directly objective this. To me empty text is not descriptive, because it's empty
Jean-Yves: What is heading in WCAG terms? That's not defined. Not sure that an empty h element would be considered as a heading
Wilco: Would then be true that empty headings don't fail WCAG at all?
Jean-Yves: And will it be sufficient to have 1.3.1 as secondary requirement for that rule?
Wilco: I don't think we should
Wilco: I keep insisting here because this work got started to push for more consistency. We changed failing empty heading in one direction, if we push in another direction we should be really clear why.
… I'm pretty sure we don't fail empty headings
… Allowing either option we probably shouldn't do
Shunguo: The only thing for me is that ARIA requires an accessible name for headings. If you provide one it'd be oK for screen reader users ,but not for users who rely on vision
Wilco: The empty heading rule that we have fails only ARIA
… If it's OK to the group I am proposing that we poll
Kathy: I just wanted to make sure we're all aware of the WG draft response
Kathy: We can take a decision but it'd be override by them at some point
Poll:
Option 1: remove the inapplicable example about an empty heading
Option 2: Leave it in, close the issue
Option 3: remove the inapplicable example, and put empty heading as a failure of 1.3.1 and 2.4.6 again
Kathy: IF we remove the inapplicable example, does that mean it's up for interpretation?
Jean-Yves: The applicability will still be attached to non-empty headings. It'd say that but we wouldn't be testing it
Wilco: Official failure but we're not enforcing it
Option 3 update: and revise the rule to fail empty headings
Wilco: For option 3 we'd have to revisit the rule
<Shunguo> Option 3
What is your preferred solution, and do you object to any of these?
Prefer 2, object to 1
<Kathy> preferred: 2; object to 3
<Shunguo> prefer Option 3
<Jean-Yves> Prefer 1, no real objection but not sure we have bandwidth for 3…
<giacomo-petri> 1 > 3
<Sage> Prefer option 2, no objections
Wilco: Not come to an agreement, we'll put together a survey
Wilco: I apologize for this, but we've had this conversation several times. I do appreciate you bringing this in again, giacomo-petri
Kathy: Good discussion, it shows how accessibility support can have an impact on interpretation