Update pagination according to mockupos

[matt-bernhardt]

Why are these changes being introduced:

The GDT project has called for an update to how pagination is shown, across all instances of this app. The details are linked from the ticket below.

Relevant ticket(s):

https://mitlibraries.atlassian.net/browse/gdt-172

How does this address that need:

• The visual display of the pagination links is changed, including which data points are included. Importantly, we are moving from a display that uses page numbers to one that uses result counts - so there are changes to the analyzer model to reflect this UI.

• We also improve the accessibility of the pagination element by using a nav element, and adding aria labels to make the screen reader output more coherent.

• Tests for both the helper and analyzer are also updated to expect the new markup.

Document any side effects to this change:

• The analyzer test gets some additional assertions because of the calculations for the first and last record in the overall range.

• The div containing the summary of the current page is still wonky on a screen reader, lacking context in its output. For example, the text 21 - 40 of 95 is read as:

21 40 of 95

My instinct would be for output like:

Showing records 21 to 40 of 95 total

However, that would involve either extensive screenreader-only spans (which are read individually, it seems?), or clobbering the whole element with an aria-label, which feels like overkill.

I'd like to ask about this during QA, however, but would encourage the reviewer to listen using VoiceOver to experience it for yourself.

Developer

Environment

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• No ENV changes

Accessibility

• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)

Stakeholder

• Stakeholder approval has been confirmed
• Stakeholder approval will come during QA (after this merges)

Requires database migrations?

NO

Includes new or updated dependencies?

NO

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

[coveralls]

Pull Request Test Coverage Report for Build 8007744021

Details

• 0 of 6 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.002%) to 99.454%

---

Totals
Change from base Build 7980541689:	0.002%
Covered Lines:	364
Relevant Lines:	366

---

💛 - Coveralls

[matt-bernhardt]

The Codeclimate flag is complaining about the complexity of the initialize method on the analyzer - which now does more calculation directly. I'm open to making the start and end parameters into separate methods, if you think it will help.

[jazairi]

I agree with your screen reader a11y concerns. My instinct is to eschew the dash altogether and have it read as, e.g., 1 to 20 of 100, but if that's too visually unappealing, then sr tags feel viable (albeit a bit messier). I think we should mention this to Darcy during QA and suggest a few options.

Not at all worried about CodeClimate's complexity concern. It's only a hair above the threshold, anyway.

Thanks for the quick turnaround on this!