Ticket #11978 (confirmed Bug)
Portlet headings should include heading tags for accessibility
Reported by: | rmattb | Owned by: | rmattb |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | Templates/CSS | Version: | 4.2 |
Keywords: | accessibility | Cc: | rmattb |
Description (last modified by rmattb) (diff)
Issue:
Sections of a page should be marked with heading tags. Screen reader users often browse through a list of all the headings on a page to find the sections, and portlets are not currently included in such a list.
Recommendation:
Extend the established pattern of the hidden h5 (in global nav, personal tools, and document actions) to portlet headers by adding an h5 for all portlet types. This appears to be the least-invasive change that will make the portlets accessible from a heading list.
Since screen readers read serially, the level of the heading is only indicated by its number (1-6). You might say that screen readers provide limited depth perception. :) This is why screen reader users are mostly interested in the simple presence of h tags, and not as interested in their levels and nesting outside of the main content; so continuing to use more h5 headings for portlets will be a very welcome improvement. ( In future development, ARIA landmark roles will address this very elegantly, but ARIA is not finalized, and not all assistive technolgies support it yet.) Regarding heading numbers/levels, one user who is blind says, "I really don't care about the numbers."
If the portlet does not have a title, or the heading is not displayed (via the checkbox setting), follow the established pattern of the navigation portlet by populating the h5 with the type of the container/collection/etc.
One screen reader user (at least) would also like to add a heading for the footer, also.
Thanks to jdeluca, cjohansen, & esteele for discussion of this issue.
Attachments
Change History
comment:6 follow-up: ↓ 7 Changed 5 years ago by trs22
In looking at the HTML spec, it looks like an h(1|2|3|4|5|6) heading tag is not valid inside a <dt>. Another option is to remove the <dt> entirely, and place the header above the <dl> element. That may break a bunch of themes that style dt.portletHeader, but I'll take a look and see how much of an issue that would be to implement.
comment:7 in reply to: ↑ 6 Changed 5 years ago by rmattb
Replying to trs22:
In looking at the HTML spec, it looks like an h(1|2|3|4|5|6) heading tag is not valid inside a <dt>. Another option is to remove the <dt> entirely, and place the header above the <dl> element. That may break a bunch of themes that style dt.portletHeader, but I'll take a look and see how much of an issue that would be to implement.
Ahh thanks for the catch - a block-level element can't be inside an inline element. However, reversing the nesting (h2 outside of dt) apparently doesn't pass http://validator.w3.org either.
So it appears that there's no way in HTML 4 to retain the semantic benefits of dl dt dd (explicitly associating text with a list) while adding the accessibility benefit of a heading. This seems to leave the best option as replacing the definition list with a heading and unordered list, which would affect existing themes. (Some discussion suggests that change this might have SEO benefits, http://bit.ly/qKEXJj .)
Adding headings to portlets is a larger change to Plone's templates than it originally appeared to be. Perhaps the solution to this should be a PLIP to get more eyes on it.
comment:9 Changed 4 years ago by rmattb
It appears that the best solution is to add hidden headings before each definition list, using h5 like this pattern which already exists in stock Plone:
<h5 class="hiddenStructure">Personal tools</h5>
<h5 class="hiddenStructure">Sections</h5>
<h5 class="hiddenStructure">Document Actions</h5>
<h5 class="hiddenStructure" tal:condition="view_actions" i18n:translate="heading_views">Views</h5>
(However, these headings are technically a bit different from the portlet headings, since they're not for columnar content mentioned in http://www.w3.org/TR/WCAG20-TECHS/H42#H42-ex2 . Adjustments to them are being planned in https://github.com/plone/plone.app.layout/pull/10 . This change will have a huge effect on the headings compliance reported by most tools, since the page will start with an H1, avoiding the limited support most tools have for passing http://www.w3.org/TR/WCAG20-TECHS/H42#H42-ex2 .)
comment:11 Changed 4 years ago by rmattb
- Summary changed from Portlet headings should include heading tags to Portlet headings should include heading tags for accessibility
comment:13 Changed 4 years ago by rmattb
- Version set to 4.1
Code for this in Plone 4.1 has been tested with JAWS, VoiceOver, and NVDA is at https://weblion.psu.edu/trac/weblion/log/weblion/plonetheme.psuaccessiblesunburst/trunk
comment:15 Changed 4 years ago by rmattb
Also include plone/app/portlets/portlets/language.pt
comment:16 Changed 4 years ago by rmattb
Will wait to commit these until the next 4.2 release is completed, to avoid confusion.
These cover anonymous visitors only, since WCAG 2.0 AA does not include authoring views.
comment:18 follow-up: ↓ 19 Changed 3 years ago by maartenkling
Is this related to ?
https://github.com/plone/plone.app.layout/pull/10
I'm not preferring the h2 elements in the columns one / two as they are rendered before the h1 in portal-column-content
comment:19 in reply to: ↑ 18 Changed 3 years ago by rmattb
Replying to maartenkling:
Is this related to ? https://github.com/plone/plone.app.layout/pull/10
No, not technically at this point, since the above changes did not include columnar content, and this ticket does.
I'm not preferring the h2 elements in the columns one / two as they are rendered before the h1 in portal-column-content
Can you explain what you're seeing? As far as I can remember we've always had this DOM order:
<div id="portal-column-content" class="cell width-1:2 position-1:4"> <div id="portal-column-one" class="cell width-1:4 position-0"> <div id="portal-column-two" class="cell width-1:4 position-3:4">
Thanks!
comment:20 Changed 3 years ago by maartenkling
rmattb: In default your right, but when using diazo this can easily be hustled around.
comment:21 Changed 3 years ago by rmattb
Information on the (lack of) search engine implications of such a change:
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=66353
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=66359
http://searchenginewatch.com/article/2199092
comment:23 Changed 3 years ago by rmattb
- Milestone changed from 4.x to 5.0
Changed milestone to next major version, due to theming backward incompatibility.
comment:24 Changed 3 years ago by rmattb
There is also an effort underway to replace the definition lists because EU guidelines recommend only using them for actual semantic terms with definitions - not generally the case here.
comment:25 Changed 2 years ago by bslash
much work has been on this at the Cologne2014 sprint, still some mopping up to be done but basically done.