<figure> requires a 'title' attribute for accessibility?

[jstallent]

I have been testing some of my sample files with Alpha7 and came across this error. Can someone tell me why <figure> is considered a non-text element and requires a title attribute, especially in a case like this, where there is already a TON of other accessibility functionality built in?

<figure id="image_alamo01">
    <div class="center"><img class="imglarge" id="image01" aria-describedby="capt_image01" src="images/image01.jpg" alt="The Alamo, San Antonio" title="The Alamo, San Antonio"/></div>
    <figcaption>
        <p class="caption">The Alamo, San Antonio</p>
        <p class="subcaption">&#x201C;Thermopyl&#x00E6; had her messenger of defeat; the Alamo had none&#x201D;</p>
        <details id="capt_image01">
            <summary>Description</summary>
            <p>The picture shows the Alamo as seen in the early 20th century. It is seen in grayscale with a wrought iron fence in the forefront.</p>
        </details>
    </figcaption>
</figure>

[pkra]

IIUC, a11y best practice is to generally avoid the title attribute, e.g., http://www.paciellogroup.com/blog/2012/01/html5-accessibility-chops-title-attribute-use-and-abuse/

[mattgarrish]

This was also questioned on the mailing list earlier, too: https://groups.google.com/d/msg/epubcheck/_B8NPwiQtkQ/WRvj6LIZpxwJ

It's not a useful accessibility aid in these cases, and is probably going to lead to wasted time and questioning of what exactly is supposed to be in the title when there are better description mechanisms available (aria-describedby, as above).

Beware of details, though, as it's been dropped from HTML5 now. Still in for 5.1, but it remains to be seen what happens validation-wise to the lost elements.

[jstallent]

Matt,

Was <details> removed recently? When I made this document a few months ago I could swear that was still the recommended method. Do you have any suggestions for an easy way to keep up with these things?

Also, I have to say that the messaging system being used in EPUBCheck 4 is a bit frustrating. If something in an EPUB file is not actually broken according to the spec then it should not be marked as a Warning. I know this has been discussed in other threads, but this is another example of a time when a best practices message would make more sense. Plus, as Peter noted, using title is not really a best practice anyway.

[mattgarrish]

The details element was always at risk for removal from HTML5, and was only recently was dropped as they move to REC (back sometime around April, IIRC). The best place to watch for these developments is the public html mailing list, although there are only a few at-risk features left (ruby model, input/time and DataCue). For a quick recap of what they dropped, see [1].

The use of details was a suggested means of making descriptions available to all readers, definitely, but some places it’s been recommended without the at-risk caveat (diagram, for example). I still think it’s a good long-term solution, the only concern is what now becomes of it in the near-term. It's been valid to use in EPUB documents for three years, so making it suddenly an error is problematic, but strictly speaking it is until EPUB 3 moves to 5.1.

I honestly don’t know what happens, that’s why I raised the concern; I only follow the list and issues, too. It’s possible that validation might not be strict to the final 5.0, but allow some laxity for the features that have been punted forward. That’s at least a thought Romain had expressed about this earlier when we talked.

I’m not trying to scare you off it, in other words, but knowing what is going to happen with respect to the dropped elements/attributes would be a big help to deciding whether to continue suggesting use.

And, of course, it doesn’t mean using details won’t work in those browser cores that already have some support the element (webkit and gecko), but I know warnings and errors can cause problems getting books into stores.
[1] http://matt.garrish.ca/2014/05/lost-from-html-5-0/

Matt
From: jstallent
Sent: Wednesday, July 30, 2014 10:51 AM
To: IDPF/epubcheck
Cc: Matt Garrish
Subject: Re: [epubcheck]

requires a 'title' attribute for accessibility? (#407)

Matt,

Was removed recently? When I made this document a few months ago I could swear that was still the recommended method. Do you have any suggestions for an easy way to keep up with these things?

Also, I have to say that the messaging system being used in EPUBCheck 4 is a bit frustrating. If something in an EPUB file is not actually broken according to the spec then it should not be marked as a Warning. I know this has been discussed in other threads, but this is another example of a time when a best practices message would make more sense. Plus, as Peter noted, using title is not really a best practice anyway.

—
Reply to this email directly or view it on GitHub.

[jstallent]

Thanks, that's very helpful. I'll switch from details to aside for now just to be safe.

Regarding the title attribute, it seems to me that we have two things happening in EPUBCheck: 1) The tool should not have a rule about the use of title attributes on non-text elements. That attribute is not actually helpful for accessibility, and its use, especially in cases like this, would be overkill. 2) The larger question of Warnings/Errors vs. Information/Best Practices messaging needs to be addressed. A file that is valid according to the EPUB spec should not finish with Warnings.

Point 1 applies most to this thread. Point 2 may be better discussed on #376.

[mattgarrish]

Right, agree on the title warning. At least narrow it to the cases where it's more relevant (iframes and form elements) and account for whether aria-label has been set, since it's replacing title use these days.

I recommended aside to another person who had the same concerns, and while hiding it may limit access to AT users, doing so at least has broader support (in reading systems and browsers generally).

I'm also hoping to prod someone into a statement about what happens now with details, as we really do need to figure out whether it can be used in a "valid" HTML5 document. Maybe I'll throw this question out on the EPUB WG list and see what happens...