Simplify pagination pattern

[aardrian]

Describe the issue

The pagination is unnecessarily verbose and can cause challenges for voice and Braille display users.

URL

Pagination

Recommended solution

1. Remove all the visually-hidden text.
2. Remove all the aria-labels.
3. Use hidden text to name the landmark with aria-labelledby.

Maybe something like:

<nav aria-labelledby="Pagination">
    <h2 id="Pagination" class="visuallyhidden">Pagination</h2>
    <ul>
        <li><a href="path/to/page">Previous</a></li>
        […]
        <li><a href="#" aria-current="page">8</a></li>
        […]
    </ul>
</nav>

Additional context

Breaking this down for how it works, the experience, and specific examples.

How the Code Works

• The pagination is in a navigation region (<nav>) and that navigation region has an accessible name of “pagination” via the aria-label.
• Nearly every page number has a visually-hidden <span> “page” pre-pending the number, giving them an accessible name of “page #”.
• The first page link in the set also has a visually-hidden <span> “(first page)” appending the number, giving it an accessible name of “page 1 (first page)”.
• The last page link in the set also has a visually-hidden <span> “(last page)” appending the number, giving it an accessible name of “page 20 (last page)”.
• The link representing the current page drops that <span> and instead uses aria-label="page #" and adds aria-current="page" to programmatically indicate the link represents the current page.
• The links for the previous and next page also append visually-hidden <span> “page”, giving them an accessible name of “previous page” and “next page”.
• Then there is the ellipsis, which represents a gap of page numbers. It’s not a link and it also has no hidden instance of “page”.
• All of this is in a list.

The Overall Experience

• A screen reader will tell the user they have entered navigation named “pagination”.
• The screen reader will tell the user every link is to a “page” number.
• The screen reader will tell the user that the link representing the current page is to “page” and is also the “current page”.
• Both instances of aria-label may not auto translate. This means both the navigation region name and the current page.
• A voice control user won’t know that “page” is prepended to all number links and appended to the word links.
• A voice control user won’t know that “first page” is also appended to the first number link nor that “last page” is also appended to the last number link.
• This overall pattern mixes accessible naming techniques, mixing my two least preferred approaches.

Specific Examples

This is using only desktop screen readers and only the most popular ones at that. After all, free labor.

Using NVDA with Firefox:

• Navigation by landmark: pagination navigation landmark list with 11 items Previous link
• Pressing Tab↹: page 1 (first page) link
• Pressing Tab↹ to the link for the current page: page 8 link current page
• Pressing Tab↹ to the link for the current page, but with a Braille display: lnk current page page 8

Using JAWS with Chrome:

• Navigation by landmark: pagination navigation region
• Pressing Tab↹: Link Previouspage (it concatenates all of them, with novel pronunciations as a result)
• Pressing Tab↹ to the link for the current page: page 8 Current Page Link (the only one it does not concatenate)
• Pressing Tab↹ to the link for the current page, but with a Braille display: lnk page 8 (the only one it does not concatenate)

Using VoiceOver with Safari:

• Navigation by landmark: pagination navigation
• Pressing Tab↹: link, Previous page, list 11 items
• Pressing Tab↹ to the link for the current page: current page, link, page 8
• Pressing Tab↹ to the link for the current page, but with a Braille display: current pg lnk page 8

Why

The region is named “pagination” and the aria-current tells screen reader users that at least one of those is a page. This is really the only context users need. Voice users can benefit from an accessible name that matches what is shown. Braille display users can benefit from far briefer link text, particularly if using a display with few cells. Overall screen reader users get a less verbose experience.

I would probably ignore WCAG Success Criterion 2.4.9: Link Purpose (Link Only) (Level AAA) unless your own testing with users shows adding “page” to each link helps. In which case, do not visually hide “page”.

[vivienlacourba]

cc: @iadawn

[iadawn]

Looks like a more streamlined version. I am presuming that @aardrian you feel the additional information regarding first and last pages is unnecessary and that the fact it is in a list is sufficient to communicate that information? I am also assuming that the narrative in how the code works and overall experience relate to the existing solution?

[aardrian]

@iadawn

I am presuming that @aardrian you feel the additional information regarding first and last pages is unnecessary and that the fact it is in a list is sufficient to communicate that information?

The list has no bearing on this (mostly because the list position is not announced with the page number as I tab through, which could otherwise cause confusion).

The region is named “pagination” and the aria-current tells screen reader users that at least one of those is a page. This is really the only context users need.

I am also assuming that the narrative in how the code works and overall experience relate to the existing solution?

Yes. Everything that is not under the "Recommended solution" relates to the existing code. The structure of this issue follows the template this specific repo provides for filing an issue ("Recommended solution" then "Additional context"), which is why it comes first.

Also, I understand that the existing pattern may be the outcome of lots of testing with users and that things I suggest would create problems for those users. That's also why I provided screen reader exposure details and the "Why" section to explain my overall reasoning -- so you can decide if that makes sense for this pattern for these users.

[iadawn]

No problem with the proposed change... although I was not here for any testing that may have occurred.

[NicolaSaunders]

I can share Word document of the testing report that includes the feedback we had on pagination. Please let me know if you would like me to do that here. It was flagged as a low priority WCAG SC 2.4.9 issue, as noted in the OP.

[iadawn]

Thanks @NicolaSaunders if you could share that directly to me please: kevin@w3.org