E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Steve Green
Date: Mon, Sep 14 2020 7:08PM
Subject: Title attribute for iframes
No previous message | Next message →

It is very common for testers and automated tools to report a WCAG non-conformance if an <iframe> element does not have a "title" attribute. However, I cannot find anything in WCAG that requires this. Can anyone point me towards such a requirement?

The Deque axe tool reports the absence of a "title" attribute as a violation of SCs 2.4.1 Bypass Blocks and 4.1.2 Name, Role, Value, both of which are highly improbable. Digging into it, it turns out that axe is referring to https://www.w3.org/WAI/WCAG21/Techniques/html/H64, which is a technique that can be used in a couple of very specific situations, neither of which is applicable in most cases. Even then the "title" attribute is only a small part of a possible solution, not a requirement.

Furthermore, that page also says "The title attribute is not interchangeable with the name attribute. The title labels the frame for users; the name labels it for scripting and window targeting." Therefore, the absence of a "title" attribute cannot be a non-conformance of SC 4.1.2 (Name, role and value) even if that SC applied to <iframes>, which it does not (it only applies to "user interface components", which are defined as "a part of the content that is perceived by users as a single control for a distinct function").

The only SC I can find that could possibly require the "title" attribute is SC 1.1.1, but that seems to be a very long stretch for me. If all the contents of the <iframe> are fully WCAG conformant, why would the <iframe> need a text alternative? And if it does, why don't other containers such as <form> elements? Or <div>s?

Finally, I should mention that for the purposes of this discussion I am only interested in WCAG conformance, not screen reader behaviours, best practices or anything else.

As always, your thoughts would be very welcome.

Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
 
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2

From: Jonathan Avila
Date: Mon, Sep 14 2020 7:14PM
Subject: Re: Title attribute for iframes
← Previous message | Next message →

The challenge is that in some browsers the iFrame appears in the focus order. Iframes (and in the past frames) may have been used to communicate a separate portion or pane of a site. Some iFrames are used for specific components, like text editors, video players and widgets. Thus, historically the industry have treated them like a component. If the iFrame was removed from the focus order and the content did not act like a user interface component that needed to be labelled then it might not need a name to meet the requirements -- but it's hard to tell this with an automated tool -- so it's safest to flag these.

Jonathan

From: Steve Green
Date: Mon, Sep 14 2020 7:51PM
Subject: Re: Title attribute for iframes
← Previous message | Next message →

Thanks Jonathan. I understand why tools report it, but it sounds like a user agent issue. If I am correct, tools should flag it as a "best practice", not a WCAG violation.

You refer to the need for a focusable element to have a label, but I do not believe that is a WCAG requirement either. The definition of a "user interface component" means that SC 4.1.2 will almost never apply to an <iframe> element.

My argument isn't so much with tool vendors, it's with testers who copy and paste the results from the tool into the report they give the client without giving any consideration to whether the results are correct. We are currently defending a client against a claim from a third party who has done precisely that. In contractual terms, the only thing that matters is strict WCAG conformance - the user experience is irrelevant.

Steve

From: Joe Humbert (A11y)
Date: Mon, Sep 14 2020 8:32PM
Subject: Re: Title attribute for iframes
← Previous message | Next message →

In the definition of "User Interface component", it states:

"Note

Multiple user interface components may be implemented as a single
programmatic element. Components here is not tied to programming techniques,
but rather to what the user perceives as separate controls. "

If an <iframe> has a tab stop it may be perceived as a individual control by
users and therefore would fall under the definition of a "User Interface
component".

Also an <iframe> element by its nature is a single element where it's
function is to load in and contain multiple other elements. An ARIA tablist
similarly contains multiple other interactive elements, would you not fail
the set of tabs under 4.1.2 Name, role and value if it did not have an
aria-label or aria-labelledby attribute?

If the same iframe is used on multiple pages and cannot easily be skipped
(possibly because the user does not understand without navigating into its
content because it has no title attribute), this could be a failure of 2.4.1
Bypass Blocks

I disagree with What you state here:

Furthermore, that page also says "The title attribute is not interchangeable
with the name attribute. The title labels the frame for users; the name
labels it for scripting and window targeting." Therefore, the absence of a
"title" attribute cannot be a non-conformance of SC 4.1.2 (Name, role and
value) even if that SC applied to <iframes>, which it does not (it only
applies to "user interface components", which are defined as "a part of the
content that is perceived by users as a single control for a distinct
function").

The name attribute in HTML is not intended to be the equivalent of the text
node, it is the equivalent of a id or other programmatic/scripting
identifier. The Title attribute, however, was intended to serve as the
visual label (in certain cases ) and accessible name of this element. In the
HTML spec this is part of the definition " on interactive content, it could
be a label for, or instructions for, use of the element; and so forth. The
value is text." (https://html.spec.whatwg.org/#the-title-attribute)

Personally, in my own personal and professional testing, I have often
inadvertently navigated into an iframe often containing hundreds of lines of
code using screen readers. While the optimum solution would have been to
hide this content for these users or include it using another method, having
a title attribute would have given myself and other real world users a hint
when we first encountered the iframe that it should be skipped.


Thankx,
Joe Humbert
Accessibility Champion
Android & iOS Accessibility Novice

From: Patrick H. Lauke
Date: Tue, Sep 15 2020 12:51AM
Subject: Re: Title attribute for iframes
← Previous message | Next message →

Related to this, there's been some back and forth here
https://github.com/w3c/wcag/issues/929 (as part of a wider discussion on
whether or not a "name" needs to be unique/descriptive)

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Mallory
Date: Wed, Sep 16 2020 1:37AM
Subject: Re: Title attribute for iframes
← Previous message | Next message →

I've taken the "interactive thingies need a name" as far as when we're forced to make an overflow area scrollable with a tabindex (unfortunately, only Firefox does this automatically). An example I run across consistently are chat widget windows. A sighted keyboarder needs to be able to scroll those to read them, and they may have zero focusables inside.

Taking the spirit of the idea that "if I can Tab and land on it, it should have a name" I'll suggest naming those if it's not possible to get rid of the overflow (scrollable areas suck).

Note that, unless it's changed, JAWS for me has always ignored iframe titles, and announced the name of the document inside (in the actual <title>). I do need to get an upgrade though.

If a client wants to say "that's not specifically required by the WCAG" that's up to them and I move on. The world is burning anyways.

cheers,
_mallory

On Tue, Sep 15, 2020, at 8:51 AM, Patrick H. Lauke wrote:
> Related to this, there's been some back and forth here
> https://github.com/w3c/wcag/issues/929 (as part of a wider discussion on
> whether or not a "name" needs to be unique/descriptive)
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Steve Green
Date: Wed, Sep 16 2020 2:10AM
Subject: Re: Title attribute for iframes
← Previous message | Next message →

It's not that the client doesn't care. This is a contractual dispute over whether a developer built a website that is WCAG conformant.

Some people on this list only work in one context i.e. achieving the best level of accessibility they can for their employer. Others of us work in a variety of contexts. Sometimes a client wants us to help them achieve the highest possible level of accessibility. Other times we might be assessing a third party website on behalf of a client before they buy a system, in which case no remedial work will be possible - they just want to understand its conformance level. In this case we are acting as independent technical assessors to resolve a disagreement.

In some of these contexts the user experience and assistive technology behaviours are completely irrelevant. All that matters is whether a website conforms with what WCAG actually says, not what anyone thinks it should say. We have to put our personal opinions aside and base our decision on the facts, even if we don't like them.

The discussion that Patrick's email links to (https://github.com/w3c/wcag/issues/929) is interesting. With one exception, everyone is of the opinion that an<iframe> is not a "user interface component", which is also my view. The one dissenting view (http://www.davidmacd.com/blog/is-title-attribute-on-iframe-required-by-wcag.html) is a very poorly argued opinion that starts with the result he wants and works backwards to justify it.

Mallory's argument starts with the statement that <iframe> elements receive focus in some browsers. This raises the obvious question of whether they should. Is there a specification somewhere that mandates this? If not, you can't use it as the basis of a justification for making the "title" element mandatory. I could equally say that it doesn't receive focus in some other browser, so the "title" attribute is not needed. We need to dig deeper, but I am not sure where to look.

Steve

From: Patrick H. Lauke
Date: Wed, Sep 16 2020 2:54AM
Subject: Re: Title attribute for iframes
← Previous message | Next message →

On 16/09/2020 09:10, Steve Green wrote:
> It's not that the client doesn't care. This is a contractual dispute over whether a developer built a website that is WCAG conformant.

And this is where the wooly, handwavy, often quite undefined/up to
interpretation WCAG crashes on the shores of binary pass/fail ... and
auditors end up having to do judge/lawyer work, reading the tea
leaves/entrails of what "the founding fathers of WCAG intended"...

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
--
Inclusive Design 24 (#id24) https://inclusivedesign24.org

From: Mallory
Date: Sat, Sep 19 2020 3:08AM
Subject: Re: Title attribute for iframes
← Previous message | No next message

"This raises the obvious question of whether they should. Is there a specification somewhere that mandates this? If not, you can't use it as the basis of a justification for making the "title" element mandatory."

No, this appears to be a decision by Mozilla to ensure sighted keyboarders can see content. Iframes tend to have a default rendering size which is usually smaller than a web document, so I've assumed iframes get focus for the same reason FF gives scrollable/overflow-hidden areas focusability.

cheers,
_mallory

On Wed, Sep 16, 2020, at 10:54 AM, Patrick H. Lauke wrote:
> On 16/09/2020 09:10, Steve Green wrote:
> > It's not that the client doesn't care. This is a contractual dispute over whether a developer built a website that is WCAG conformant.
>
> And this is where the wooly, handwavy, often quite undefined/up to
> interpretation WCAG crashes on the shores of binary pass/fail ... and
> auditors end up having to do judge/lawyer work, reading the tea
> leaves/entrails of what "the founding fathers of WCAG intended"...
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> --
> Inclusive Design 24 (#id24) https://inclusivedesign24.org
> > > > >