Pagination issues and considerations

[mbgower]

This is an omnibus issue covering the Pagination component, resulting from an accessibility review. In addition to the top items covered here, there is specific and more detailed material covered in commented PDFs of Usage and Style pages that should be reviewed.

• The following sections are missing from the Usage: Formatting, Anatomy, Placement, Content, Behaviors, Related, References. Given the extreme relevance of at least data table and filtering patterns, this seems like a pretty big omission.
• There is a whole pagination section in Data table. i wonder whether that information should be relocated here, or is at least harvested for what content is not unique to a table pagination interaction.
• Note that the data table's indetermine version of pagination does not seem to perfectly align with that shown in the Live demo
• The labelling is not great for a screen reader, and I think there could be ways of making it better. The simplest is:
  "Page: [12 of 40]v" instead of "[12]v of 40 pages" I've used the "[ ]v" to represent where the input and down chevron is/could be. That would need to be tested, but with zero real difference to a sighted user could likely be a much better screen reader or magnified result. Note that this also works when the unknown variant is enabled
  
  
  There are more holistic changes that could be made, but this would be a pretty easy one to do.
• the current design also requires you to do something with the 'orphan' text when it comes to building a label. At the moment, Carbon has used a hidden aria label that is populated based on values on screen, but I think an aria-describedby is more elegant and also better supports internationalization
  <label for="cds-pagination-select-id-5-right" class="cds--label cdes--visually hidden">Page number, of 6 pages</label>
  They could just take the select itself and use aria-describedby to link it with an ID they assign to
  <span class"cds--pagination__text">of 6 pages</span>
  The speech output with Jaws is much smoother, IMO. I've made a small recording of current and improved screen reader behaviour. If combined with the above suggestion on labelling changes, this would result in real improvement.
• the chunk of text after the first input ("1 to 10 of 103 items" in the image above) should be tested as a live region. The advantages of this: when a user incremented the prior or next pages, or when a user changed the number of records shown OR potentially when the filtering was altered, this would be announced by the screen reader. Could be VERY useful.
• seem to be unintended duplicates at the bottom of the Usage page
• the page totals used in an illustration on the style page do not make sense
• Speaking of putting "Page" in front of the right-side input, almost all the variations in Figma already show that, so it would result in a more consistent layout

[laurenmrice]

Website docs:

• Add a section for "Responsiveness" and how the pagination content should change and respond depending on the breakpoint. Only pertinent information should remain in the pagination component at smaller breakpoints.

[laurenmrice]

Closing in favor of the following issues where the work for this will be tackled and cross-referenced:

• Website: [Pagination, PaginationNav] update Usage docs #4013
• Website: [Pagination, PaginationNav] update Style docs #4021
• Code: [Pagination]: improve order of select labeling for screen readers carbon#16538