Wcag: Can title on links (e.g. linked icon) as sole source of accName ever pass 1.1.1?

[detlevhfischer]

This is an old discussion but the question appears time and again.
An unlabelled icon (e.g. font icon with aria-hidden, SVG without title, CSS-generated content on a span) sits in a link that receives its accName from the place of last resort, the title attribute (on the link). Advantage for sighted mouse users: the title acts as additional tooltip, redundant exposure of accName by screen readers is minimised.
I have not done extensive testing across UA and AT (add information on other cases) but I believe _mostly_ title is ideed exposed as accName (in line with the accName algorithm).
This is not a question about best practice: Please refrain form telling me how it should be done. This is merely the question whether we need to accept (i.e. pass 1.1.1) content that only has title, or whether we should fail content in this situation.

[stevefaulkner]

@detlevhfischer if the image is hidden from AT then it pass 1.1.1 no? it would be then dealt with under 4.1.2 Name, Role, Value (A) no?

[detlevhfischer]

@stevefaulkner My line of thinking would have been: Theres is an image (only) which is not an img element which needs an alternative - whether provided by hidden text, aria-label,title on itself or on elements that include it. I therefore see it as a candidate falling under 1.1.1 and consider the question of whether it falls under 1.1.1 or 4.1.2 as secondary. The question would then only shift to 4.1.2: Pass or Fail? To what extent will PASS/FAIL be dependent on the current situation regarding a11y support across the commonly used UA/AT combinations (assuming this is general web content). Or is there a principled line: title can never alone be used to pass 1.1.1 (or 4.1.2)?

[stevefaulkner]

OK so take a simple case:
<img title="blah">
If the title content provides an appropriate accessible name for the context the img is used is, then it passes, is my understanding. This technique suggests it does https://www.w3.org/TR/WCAG20-TECHS/F65.html
Extending this to your use case:
<a href=# title="blah"><img alt=""></a>
would pass

[mraccess77]

It has been used for years to pass.

[LaurenceRLewis]

There are still issues for some users in using the title attribute alone.
3.2.6.1 The title attribute

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

The suggested use for the title is to supplement link text as described in H33: Supplementing link text with the title attribute

The follow is stated on this page:

Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique...

Another compelling argument against using the title attribute alone is described in the post Using the HTML title attribute – updated by @stevefaulkner

The following documents support using the title attribute alone.

• H64: Using the title attribute of the frame and iframe elements
• H65: Using the title attribute to identify form controls when the label element cannot be used as mentioned by Steve Faulkner

As far as I can ascertain the title attribute is mostly recommended for use to supply supporting information. Another case for title as supporting is H89: Using the title attribute to provide context-sensitive help

Understanding whether title alone is sufficient to pass 1.1.1 Non-text Content (A) and other criterion would be helpful in compiling more accurate and realistic accessibility reporting where the basis is WCAG.

Further information for consideration whether the title attribute alone should be an automatic pass for 1.1.1 Non-text Content (A):

A "click here" link with TITLE attribute Screen reader compatibility (PowerMapper)
https://www.powermapper.com/tests/screen-readers/labelling/a-title/
Short note on use of alt=”” and the title attribute (@stevefaulkner
https://developer.paciellogroup.com/blog/2016/02/short-note-on-use-of-alt-and-the-title-attribute/

[mraccess77]

This discussion is around title attribute use an accessible name -- not a visible label -- so any discussion regarding keyboard access to the title is out of scope from Detlev's question. This discussion is not around best practices -- but what is needed to conform. Title continues to be included in the accessible name calculation (https://www.w3.org/TR/html-aam-1.0/#a-element) and seems to have a long history of accessibility support when used as the accessible name.

[jake-abma]

Also IMHO the title has always been fine (not preferred) as a last resort. No issues there for ACC name.

[LaurenceRLewis]

This discussion is around title attribute use an accessible name -- not a visible label -- so any discussion regarding keyboard access to the title is out of scope from Detlev's question.

Thank you for clarifying @mraccess77 I misunderstood the purpose of the question.

[JAWS-test]

It violates 1.1.1 and 1.3.1, if it is a background graphic, because then the link is not visible in High Contrast Mode: https://www.w3.org/WAI/WCAG21/Techniques/failures/F3.

But title is not a problem in regard to accessible name.

[mraccess77]

@JAWS-test there are 2 separate issues discussing HCM and F3 and WCAG in general and the consensus (contrary to my personal feelings) is that WCAG does not mandate HCM specific issues that don't fall under other SC and that F3 was not indented to apply to HCM but rather AT like screen readers.

[JAWS-test]

@mraccess77: I read 1.3.1 so that it is fully applicable to HCM. I find it a pity that this is not reflected in the other documents (Failures and Techniques). It is also not clear to me how it should be handled if a browser like Chrome does not support HCM at all.

https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html

The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.

But it is also correct that HCM in F3 is only given as a note.

[patrickhlauke]

I read 1.3.1 so that it is fully applicable to HCM
[...]
The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.

This does NOT mean that it's the author's responsibility to make sure that even after a format change things are visually/auditorily formatted correctly / that after the format change the information and relationships are clear. It can't, because authors don't have control over what the format change does. The intent is that the structural etc information is conveyed programmatically (e.g. through proper markup structures), so that it is possible to make a format change that still conveys the structure/relationship. It's still up to the particular technology used to make the format change (e.g. whatever does the HCM) to ensure that it takes the programmatically exposed structure into account and displays/exposes it accordingly.

Long story short, 1.3.1 requires authors to use proper markup. This makes sure that format changes have the necessary information/hooks to know what the markup IS in order for them to then present it properly. The onus, however, is then on the format change tech to do that.

(otherwise, it would be like me writing my own custom stylesheet that simply sets everything to the same formatting / text size / color / position, and then complaining to a site that after i apply my stylesheet i can't tell anymore what a heading etc is)

But anyway, this is beside the point of this discussion, as @mraccess77 already said.

[JAWS-test]

I agree: with

Long story short, 1.3.1 requires authors to use proper markup.

because "programmatically determined: determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities" (https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable)

But: The question is, who is responsible that div role=button tabindex=0 is not recognized as a button in HCM? Should ARIA roles be considered in the HCM? Does the UAAG require this (possibly in 4.1.2, https://www.w3.org/TR/2015/NOTE-UAAG20-Reference-20151215/#sc_412)? If not, then the ARIA button would be correct code for screen reader users, but not for visually impaired users and therefore 1.3.1 would not be met.

And this isn't about nonsensical custom stylesheets. It's about a well-established assistive technology available on different operating systems.

[patrickhlauke]

But: The question is, who is responsible that div role=button tabindex=0 is not recognized as a button in HCM?

that's a user agent issue. complain to the provider of the assistive technology. it is not something that can be mandated / required from web content authors, as it's outside of their control.

[JAWS-test]

Who says so?
Where is this specified in the UAAG?

[LJWatson]

The relationship between authoring tools, web content, and user agents is well understood. WCAG2.1 includes the following statement:

Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents. Authoring tools also have an important role in Web accessibility...>

This relationship is further documented in Essential Components of Web Accessibility which is referenced from WCAG2.1.

[jake-abma]

Hi @JAWS-test

WCAG goes a long way but also stops at certain points where the content author is not in control anymore on how is being dealt with the content in alternative formats. A clear separation of responsibilities in this case is what makes a SC succeed or not.

So as an example for 1.3.1...

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

... and then see what's done with this kind of code from a known HCM of choice, we see that for...

• div role=button tabindex=0
• CSS box-shadow: valueA valueB;

... both are not properly shown, the shadow not at all, the button as if it is a text node.

The "default" presentation in both cases can be programatically determined by the HCM supplier and the responsibility to present the alternative is at their hands.

Cheers!

[JAWS-test]

Hi @jake-abma and @LJWatson

I think it is necessary according to WCAG and UAAG to distinguish:

• the HCM promises to change all colors and replace them with other colors depending on the HTML role of the element. This is required in https://www.w3.org/TR/2015/NOTE-UAAG20-20151215/#sc_142 and https://www.w3.org/TR/2015/NOTE-UAAG20-Reference-20151215/#sc_145 . This usually works well, too. So the wrong display of CSS box-shadow would be an error of the browser or operating system and not of the web developer.
• the HCM doesn't promise to evaluate ARIA roles and I haven't found any information that the UAAG requires this. Also, I don't know any example where this works in practice (if someone knows one, I'd appreciate a hint). Therefore div role=button tabindex=0 is not "accessibility-supported" with respect to HCM (https://www.w3.org/TR/WCAG21/#cc4) and a web developer may not rely on it.

[patrickhlauke]

I'll note that there is nuance to "accessibility supported". In the case of HCM, if the site has a solid contrast to begin with, the author is not relying on the use of HCM for a low-vision user / user with impaired color perception to use the content, for instance.

Also, generally, there is no cut-and-dry "it must all work in all ATs" requirement. authors are not on the hook for shortcomings of some ATs (as otherwise you'd get in a situation where a page may fail one day and pass the next, or vice-versa, depending on a bug or change in a feature of an AT - which is not a solid basis for making a normative pass/fail assessment, potentially as part of a legal case).

The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported.

Lastly, it's worth not losing track of the bigger picture here: it seems there's a desire to normatively fail things here, when really nothing's stopping auditors from saying "while this may pass WCAG, we'd still recommend that this should be changed because of X".

Anyway, this is the wrong thread to discuss HCM stuff anyway, as it's an aside to the actual point of this issue.

[detlevhfischer]

To turn back to the question whether title alone can suffice as alternative text for an image: It looks like Edge/Narrator won't use title on a link with a background image. That seems as pretty significant gap in accessibility support. Would you stand by "For 1.1.1, title is acceptable (if not recommended) as image alternative text of last resort" even with this gap in support?

[awkawk]

This is an issue of accessibility support. If you are relying on Edge/Narrator as part of your conformance claim then it wouldn't be sufficient. If you base your claim on VO/Chrome and NVDA/Chrome then it might (I don't know what the current support in these at/browser combos).

[stevefaulkner]

To turn back to the question whether title alone can suffice as alternative text for an image: It looks like Edge/Narrator won't use title on a link with a background image. That seems as pretty significant gap in accessibility support. Would you stand by "For 1.1.1, title is acceptable (if not recommended) as image alternative text of last resort" even with this gap in support?

I tested a link with a title and background image in Narrator/Edge https://cdpn.io/stevef/debug/OJNGaNX it announced the title as the acc name for the link as expected. Am I missing something?

[detlevhfischer]

@stevefaulkner Interesting, maybe something else was in play. I will check and report back.

[JAWS-test]

Sometimes a space or a line break in the link is enough for the screen reader to output it as a name and not the value in the title attribute

[detlevhfischer]

@JAWS-test bingo! That is exactly what prevented the title from being read - I removed that single space in DevTools and it works. Quite a brittle solution then to use title for providing alternative text.

[patrickhlauke]

half the web is brittle. but yes, so not a failure, author error which some browser/AT combos seem to paper over/error correct for with heuristics