-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify pagination pattern #634
Comments
cc: @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? |
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
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. |
No problem with the proposed change... although I was not here for any testing that may have occurred. |
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. |
Thanks @NicolaSaunders if you could share that directly to me please: [email protected] |
Proposed solution is at w3c/w3c-website-templates-bundle#145 |
Describe the issue
The pagination is unnecessarily verbose and can cause challenges for voice and Braille display users.
URL
Pagination
Recommended solution
aria-label
s.hidden
text to name the landmark witharia-labelledby
.Maybe something like:
Additional context
Breaking this down for how it works, the experience, and specific examples.
How the Code Works
<nav>
) and that navigation region has an accessible name of “pagination” via thearia-label
.<span>
“page” pre-pending the number, giving them an accessible name of “page #”.<span>
“(first page)” appending the number, giving it an accessible name of “page 1 (first page)”.<span>
“(last page)” appending the number, giving it an accessible name of “page 20 (last page)”.<span>
and instead usesaria-label="page #"
and addsaria-current="page"
to programmatically indicate the link represents the current page.<span>
“page”, giving them an accessible name of “previous page” and “next page”.The Overall Experience
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:
pagination navigation landmark list with 11 items Previous link
page 1 (first page) link
page 8 link current page
lnk current page page 8
Using JAWS with Chrome:
pagination navigation region
Link Previouspage (it concatenates all of them, with novel pronunciations as a result)
page 8 Current Page Link (the only one it does not concatenate)
lnk page 8 (the only one it does not concatenate)
Using VoiceOver with Safari:
pagination navigation
link, Previous page, list 11 items
current page, link, page 8
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”.
The text was updated successfully, but these errors were encountered: