W3C

Accessibility Conformance Testing Teleconference

12 Dec 2019

Attendees

Present
Wilco, Patrick, Trevor, MaryJo, KathyEng, MoeKraft
Regrets

Chair
MaryJo, Wilco
Scribe
KathyEng

Contents


Image button has accessible name (https://www.w3.org/2002/09/wbs/93339/ImgButtonName/results)

wilco: First comment by charu. Specified that we don't check if the accessible name is meaningful.
... It is fairly strongly implied.

patrick: We have had this discussion before. It seems that even with AGWG there is disagreement about this aspect. For this reason it may be good to be explicit.

wilco: specifically that the rule isn't checking, or that 4.1.2 is not looking for a meaningful name?

patrick: it started with 4.1.2. Perhaps it could be in applicability.

trevor: concerns about checking meaningfulness automatically.

wilco: We are saying we are doing it in the rule, just that we are being explicit. If we do that, it seems like it we would have to do it broadly.
... Or is there something about this specific circumstance.

kathy: I like the idea of providing the clarification, but I think the passing example with the smiley face, is providing that it is not requiring meaningfulness.
... Connecting this to other rules that specify further
... It would be nice, but it could be a nightmare to maintain.

maryjom: Perhaps we could add to the description of the passing rule with smiley.

wilco: That rule has actually been removed. I will take this back to the community group as feedback.
... Moving on to Moe's comment: "The applicability is very confusing."

<Wilco> https://act-rules.github.io/rules/59796f#applicability

moe: Not sure what was meant by: "type attribute in the Image Button state"

wilco: For clarification, the language used here is what is used in the HTML spec. Using the type attribute, puts an input HTML element into a specific state.

<patrick_h_lauke> https://www.w3.org/TR/html52/sec-forms.html#sec-states-of-the-type-attribute

moe: I know you have a link to the HTML spec within the rule.

wilco: Detlev, some of the test cases seemed identical. Yes, that is being fixed.
... Jonathan brought up a point about fallback name.
... Suggestion from Detlev to merge test cases, thats done.
... We are working to update the test case descriptions to be clearer, which is what AG is looking for.

<MoeKraft> https://html.spec.whatwg.org/#image-button-state-(type=image)

moe: the link went to input states. I think updating to the link above would be better.

wilco: Is the language clear though? I have questioned this myself. The reason it is written this way is so we have a clear description of what to do with capitalization and spacing since it is taken care of by the HTML spec.
... But it is more verbose, and is language people will probably not always be familiar with.
... So the thing that needs to change here is that we need to add in the link. Overall, seems relatively minor. Adding some link, cleaning up examples. Is that it?
... These seem like editorial that can be fixed easily enough.

iframe element has accessible name (https://www.w3.org/2002/09/wbs/93339/ValidPageLang/results)

wilco: First problem brought up by Romain,"what would be an iframe that is *not* used as a UI", questioning assumption.

patrick: Would an example be an iframe that is not a UI component one has no borders or interactable content.

wilco: That is what I would say, but not everyone treats iframes as UI components as well. It is hard to point out what exactly makes it a UI component.

patrick: If you had an iframe that has a button, I would say the button is the UI component, not the iframe.

wilco: Is it never?

patrick: If there is a handler on the iframe then perhaps it could be the UI component?

wilco: There could be something like a scroll bar, in which case it might be a UI component.

patrick: I am tending towards seeing them as containers than seeing them as UI components. Its not really different than a div that has overflow to scroll.

wilco: Is that changing how we reference 4.1.2? Does that mean iframes need accessible names.

patrick: Going in cold without testing, it seems like the best experience would be going in without having to know.

wilco: They are announced by screen readers. Treated as their own region.

maryjom: I think thats why the accessible name is required, since the assisstive technology might need to announce it when you move into the "region".

<Wilco> https://github.com/w3c/wcag/issues/929

wilco: The above link has a long discussion on iframes. It is inconclusive about what should be done.

trevor: Like thinking of it as a div. If screen readers read of when it was entered it should have an accessible name. UI component may not be the best name. Is there another?

<Wilco> http://www.davidmacd.com/blog/is-title-attribute-on-iframe-required-by-wcag.html

kathy: We test for it under 4.1.2.
... Is there anyway to bypass an iframe.

wilco: I think you can skip to, but can jump to.

patrick: Is it a failure for a region not to have an accessible name.

trevor: Can a region have an inaccessible name? its given by the region.

patrick: Perhaps when there are two navigation regions. How can they be disambiguated?

maryjom: We sometimes have some stricter rules that might fail it in that case.

patrick: Similarly, we do some similar best practice stuff, but it may not be a failure under WCAG

wilco: Sounds like we need to do some research. Everyone do some digging, and we can come back to this next time.

maryjom: H64 is looking at iframes using titles as a sufficient technique.

wilco: H64 suggests that it is part of 4.1.2. So we can disagree with H64, but if not then having a title would be a failure.
... Would it be fine to send this rule out to AG with a note that we disagree with H64 and have the conversation in a larger context.

<patrick_h_lauke> (just voicing my more fundamental concern with H64 but will discuss further with AGWG)

wilco: Romain brought up that the glossary has some accessibility interoperability issues that should perhaps also exist in the accessibility support section.

moe: Brought up issue: " think you should expand upon or explain why "All passed outcomes: further testing needed."

wilco: This wording is taken from the ACT rules format. Essentially it is saying the rest of the criteria is needed.

moe: Thinking in the shoes of someone who is testing this rule, I am trying to understand what is needed further.
... So the rule passes, but further testing is needing. So what else does it need?

wilco: That is pretty much always the case with WCAG minus a couple execptions. The scope of the rules is usually much smaller than the scope of the S.C.
... I don't really know how to answer the question other than saying everything else

moe: I am looking at some sufficient techniques that pass the rule. The outcome says further testing needed.

patrick: Any other thing that would fail, even outside the test target for this particular rule.

wilco: ACT rules are really meant to test for failures. We usually cannot tell you if it passes. It is also the nature of WCAG not be able to do that. It is future compatible, which makes it difficult.

patrick: It is almost always a given that further testing will be needed. You couldn't look at this rule and then say I don't need to test anything further.

wilco: We are going on a three week hiatus. We will reconvene January 9th.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/01/09 14:54:44 $