Wilco: Follow-up from a couple of weeks, where we decided to go on a case by case basis for what to include or not
... This is blocked until we have an answer to this question.
... Iframes are complicated in terms of their support
... Going through some examples and deciding if they pass or not.
... Iframes that use aria-label to provide accessible names work in FF and NVDA, do not work in VoiceOver and Safari, and for JAWS doesn't matter because in Chrome they are not focusable
... Should there be an example like this?
Kathy: Is the iframe keyboard focusable in Safari?
Wilco: They are a region you have to get into
Trevor: Does that include if there are focusable items in an iframe?
Wilco: If there is no content in the accessibility tree for an iframe then VoiceOver will ignore it
Kathy: If the iframe is keyboard focusable we always require that they have accessible name. It can be through ARIA or through the title. When people are testing, they note which browser they are testing in.
MaryJom: Sounds like it could be a bug on Safari
Wilco: I am not sure about that.
Kathy: I agree with that.
Wilco: That means anybody who implements this rule cannot fail iframes for using aria-label
Daniel: This is about following the spec, so as long as aria-label is in the spec, browsers should follow it.
Wilco: Same for aria-labelledby?
... Should iframes be considered interface components? They are focusable in Firefox, not in other browsers unless you put a tab stop in them.
... The HTML spec allows this, you do not have to redirect focus
Kathy: We included them under 4.1.2 because of technique H64
<Wilco> https://www.w3.org/WAI/WCAG21/Techniques/html/H64
Wilco: This does not imply there is a failure
Kathy: From our testing tool we can detect iframes regardless of whether they are focusable. I don't see this being an accessibility issue.
Wilco: When you have to navigate into them that matters
... If we don't require iframes to have an accessible name, the impact is that in Safari with VoiceOver you may have nothing in a region
... for Firefox is going to be a silent tab stop
Daniel: As long as iframes contents are focusable, requiring accnames for iframes seems not to be very much of an issue for me
Kathy: This empty tab stop would be problematic
Wilco: It will be only in Safari and Firefox
Kathy: Maybe a not to AG presenting these scenarios. Not having any information could be problematic.
Wilco: And we have approved rules which only fail in certain browsers
... My preference would be to put this rule out there with a clear accessibility support warning
... and then include aria-label and aria-labelledby examples
Kathy: I would agree with it.
Daniel: Agree.
Wilco: Do we need a CFC? Maybe not, as we will be reviewing the rule again.
<maryjom> I agree as well. I was on mute, so you didn't hear me.
<Wilco> proposed RESOLUTION: iframes without an accessible name should have a rule for SC 4.1.2, that rule must include passing examples using aria-label and aria-labelledby
RESOLUTION: iframes without an accessible name should have a rule for SC 4.1.2, that rule must include passing examples using aria-label and aria-labelledby
Wilco: Comment in question 3.
... It seems this comment is about input fields, which would not be applicable.
Kathy: For the first example, the understanding article covers that they label would be to the left and this is what should be included
Wilco: But still this rule should not apply to them.
Kathy: When I read the rule, this was not as clear to me as it is now that you have explained it.
Wilco: That might mean something. Did others experience that?
Trevor: I did not make that distinction either. Maybe it should be included in the title or description.
Wilco: Yes, this can be improved.
... This needs to explain better that this is for things that have labels inside of them.
<Wilco> https://act-rules.github.io/testcases/2ee8b8/65be0004543e57d44dd4a53d9f582c482503727c.html
Wilco: Why would you suggest this is not applicable?
Kathy: Because the icon does not have visible text
Maryjom: How would the user know about the text behind the font?
Wilco: The technical reason is because of how the technology works. There is a text node that is replaced by Fonts
Kathy: I followed the same logic. Visually what is on the screen is not text anymore.
Wilco: It is difficult to define it in an objective way so that it can be excluded from the applicability
Maryjom: But it is an icon font and we could probably exclude that since it is no longer text
Kathy: I think there are icon fonts that look like text, maybe these would be better examples. It is a magnifying glass
Wilco: This has been reported to us as a problem. If we had a definition of font icons then we could.
... Our tool was producing false positives on this.
<Wilco> https://news.google.com/topstories
Wilco: On the left there is these icons which are icon fonts
MaryJom: The issue is that the test case can't filter icon fonts
Wilco: Would it be a blocker?
Kathy: We would not set example 6 as applicable
Three surveys open, 24 and 31 December, Christmas break.