Navigate Pages via Keyboard - Left Hand Nav

* As an IAO user
* I want to be able to navigate the pages on the left hand nav with my keyboard
* so that I can more efficiently move through the records

**Assumptions & Scope**
This is a feedback request from users during usability tests. Clicking into each page in the left hand nav is cumbersome, and they would like the ability to move using the keyboards up and down arrows instead.

I am also going to recommend pgup and pgdown to move between documents for faster navigation.

When the user changes pages this way, the middle reviewer should be responsive to these changes like a key click.

What is IN scope?
Changes to navigation through the left hand nav panel

What is NOT in scope?

**Acceptance Criteria**

**Scenario 1: Moving to next Page**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click down on their keyboard arrow
* THEN the page selection will move down
* AND the page will be displayed in the review panel in the middle

**Scenario 2: Moving to Prior Page**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click up on their keyboard arrow
* THEN the page selection will move up
* AND the page will be displayed in the review panel in the middle

**Scenario 3: Move to Prior Page in new document**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click up on their keyboard arrow
* AND the prior page is the last page of a new document
* THEN the page selection will move up to the last page of the prior document
* AND the page will be displayed in the review panel in the middle

**Scenario 4: Move to Next Page in new document**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click down on their keyboard arrow
* AND the next page is the first page of a new document
* THEN the page selection will move down to the first page of the next document
* AND the page will be displayed in the review panel in the middle

**Scenario 5: Moving to next Document**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click the page down button on their keyboard
* THEN the page selection will move to the first page of the next document
* AND the page will be displayed in the review panel in the middle

**Scenario 6: Moving to Prior Document**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click the page up button on their keyboard
* THEN the page selection will move to the first page of the prior document
* AND the page will be displayed in the review panel in the middle

**Scenario 7: Moving at end of records package**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click the key to attempt to navigate down
* AND the page they are on is the last page of the overall records package
* THEN the page selection will remain on the last page

**Scenario 8: Moving at beginning of records package**
* GIVEN an IAO user is in the redaction app, and has a page selected in the left nav pane
* WHEN they click the key to attempt to navigate up
* AND the page they are on is the first page of the overall records package
* THEN the page selection will remain on the first page

**Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)**

**Validation Rules? (If yes, list here)**

**Design**
@xxx - please link the Design here

**Definition of Ready**

1. [ ] Is there a well articulated User Story?
2. [ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
3. [ ] If there is a user interface, is there a design?
4. [ ] Does the user story need user research/validation?
5. [ ] Does this User Story needs stakeholder approval?
6. [ ] Design / Solution accepted by Product Owner
7. [ ] Is this user story small enough to be completed in a Sprint? Should it be split?
8. [ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
9. [ ] Has the story been estimated?

**Definition of Done**

1. [ ] Passes developer unit tests
2. [ ] Passes peer code review
3. [ ] If there's a user interface, passes UX assurance
4. [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
5. [ ] Confirm Test cases built and succeeding
6. [ ] No regression test failures
7. [ ] Test coverage acceptable by Product Owner
8. [ ] Ticket ready to be merged to master or story branch
9. [ ] Developer to list Config changes/ Update documents and designs
10. [ ] Can be demoed in Sprint Review
11. [ ] Tagged as part of a Release
12. [ ] Feature flagged if required
13. [ ] Change Management activities done?

Start in the redaction app at the left-hand navigation and trace the existing page-selection behavior triggered by a mouse click. Implementing this requires checking keyboard focus and page/document boundaries; done means the arrow and page up/down scenarios update the middle review panel and stop at the package boundaries without regressions.

Written by the indexing model from the issue text.