a11yproject / a11yproject.com

The A11Y Project is a community-driven effort to make digital accessibility easier.
https://a11yproject.com
Apache License 2.0
3.73k stars 556 forks source link

Hiding content with details / summary #426

Closed shawnthompson closed 7 years ago

shawnthompson commented 8 years ago

In Shop Talk Show 222: RAPIDFIRE 62, you talked about using details / summary in an accessible way and asked for help. Here's what I've got...

The Web Experience Toolkit created accessible polyfill for the details / summary for our developers to use natively in code without having to worry about adding any extract markup to their source code.

Lately we've been doing some usability and accessibility tests on details and summary to see how well they work and have been getting poor results. @neoinsight is the usability expert doing the tests on our sites and she's the one who was finding problems with people accessing the information inside the details elements.

Hope this helps Shawn Longtime listener, second time issuer!

neoinsight commented 8 years ago

Basically, we advise against using Details/summary for anything essential to a task - it should hide edge-base content that is only needed by 20% of the potential users of the page. All users expect the content to be on the page if it is essential to the task - they tend to not expect to have to open a Details/Summary, thus will look elsewhere on the page rather than finding and opening content hidden in a summary.

Sighted participants are unlikely to find and use Details/Summary if it does not look like a link. We have made the WET version CSS more link-like over the last year to try to remedy this issue.

For screenreader participants, here is what we have found: Details/Summary plugins were missed in various tasks NVDA (most recent version) participant: Could not find or open it even with assistance “Maybe it’s one of those weird things that isn’t a link.” iPhone VoiceOver participant did find it but said: “It didn’t seem like something that could open – should say link or button” – same as sighted participants!

Problem is three-fold for screen-reader participants:

  1. Many Screenreader users navigate by links/headings – won’t hear it
  2. Not clear it’s something that opens (also what sighted users say)– but it is to spec, screen readers need to catch up
  3. Used too frequently for primary content, instead of details
joe-watkins commented 8 years ago

@shawnthompson @neoinsight Wow this is great insight from real user testing :) I'd add that no IE support at all is big concern for robustness. http://caniuse.com/#search=details

shawnthompson commented 8 years ago

@joe-watkins that's why we use a polyfill for it, so it's supported in all browsers. When you validate a page against with the W3C validation tool, it warns "the details element is not supported in all browsers. Please be sure to test, and consider using a polyfill."

Our Tabbed interface in our framework uses details/summary for it's source code. All our aria attributes and accessibility elements are injected with JS so our HTML authors don't need to worry about know any of that.

Example:

HTML code

<div class="wb-tabs">
    <div class="tabpanels">
        <details id="details-panel1">
            <summary>Example 1</summary>
            <p>
                ...
            </p>
        </details>
        <details id="details-panel2" open="open">
            <summary>Example 2</summary>
            <p>
                ...
            </p>
        </details>
        ...
    </div>
</div>

Turns into this:

<div class="wb-tabs wb-init wb-tabs-inited tabs-acc wb-eqht wb-eqht-inited" id="wb-auto-2"><ul class="generated" aria-live="off" role="tablist" aria-hidden="false" style="vertical-align: top; min-height: 46px;"><li role="presentation"><a href="#details-panel1" id="details-panel1-lnk" tabindex="-1" role="tab" aria-selected="false" aria-controls="details-panel1">Example 1</a></li><li class="active" role="presentation"><a href="#details-panel2" id="details-panel2-lnk" tabindex="0" role="tab" aria-selected="true" aria-controls="details-panel2">Example 2</a></li><li role="presentation"><a href="#details-panel3" id="details-panel3-lnk" tabindex="-1" role="tab" aria-selected="false" aria-controls="details-panel3">Example 3</a></li></ul>

    <div class="tabpanels" style="vertical-align: top; min-height: 77px;">
            <details id="details-panel1" class="wb-auto-2-grp open fade noheight out" role="tabpanel" open="open" tabindex="-1" aria-hidden="true" aria-expanded="false" aria-labelledby="details-panel1-lnk">
                <summary class="wb-init wb-toggle tgl-tab wb-toggle-inited wb-details-inited" data-toggle="{&quot;parent&quot;: &quot;#wb-auto-2&quot;, &quot;group&quot;: &quot;.wb-auto-2-grp&quot;}" aria-hidden="true" id="wb-auto-3" role="tab" aria-selected="true" tabindex="0" aria-posinset="1" aria-setsize="3" aria-expanded="true">Example 1</summary><div class="tgl-panel" aria-labelledby="wb-auto-3" aria-expanded="true" aria-hidden="false">
                <p>
                ...
                </p>
            </div></details>
            <details id="details-panel2" open="open" class="wb-auto-2-grp open fade in" role="tabpanel" tabindex="-1" aria-hidden="false" aria-expanded="true" aria-labelledby="details-panel2-lnk">
                <summary class="wb-init wb-toggle tgl-tab wb-toggle-inited wb-details-inited" data-toggle="{&quot;parent&quot;: &quot;#wb-auto-2&quot;, &quot;group&quot;: &quot;.wb-auto-2-grp&quot;}" aria-hidden="true" id="wb-auto-4" role="tab" aria-selected="true" tabindex="0" aria-posinset="2" aria-setsize="3" aria-expanded="true">Example 2</summary><div class="tgl-panel" aria-labelledby="wb-auto-4" aria-expanded="true" aria-hidden="false">
                <p>
                ...
                </p>
            </div>
                     </details>
        </div>
</div>

I think it's pretty neat and well thought out.

davatron5000 commented 7 years ago

Following up on this. Any resolutions we'd like to make? I'd love a definitive "How to: Make a basic tabs/accordion component" article.

re: Using <details> - Thanks for the data, @neoinsight. Very valuable. Makes sense since hidden content fails sighted users too.

joe-watkins commented 7 years ago

Looks like Edge is wrangling details/summary now! :)

https://developer.microsoft.com/en-us/microsoft-edge/platform/status/detailssummary/?q=details

svinkle commented 7 years ago

@davatron5000 @joe-watkins, any new movement on this issue?

joe-watkins commented 7 years ago

Closing -- @shawnthompson 's usability findings lead one to think details/summary isn't best method of showing/hiding content... at least enough to form a definitive guide. Might have to wait for AT to catchup.

We have a couple tab patterns and a toggle folks can take a peek at.