Appointment Request: Create Calendar View - Direct Flow

[MekoHong]

Description

As a user, I would like to provide my date and time preferences that work for me when making an appointment request

As part of this story we want to:

• Create a calendar view to support the Appointment Direct workflow

Acceptance Criteria

1. Create calendar modal- Direct Calendar View 2. Verify Close is displayed on the top left 3. Verify title reads 'Choose preference' 4. Use the Calendar component for the calendar display 5. Verify the following rules are implemented when displaying the calendar - The calendar starts on the month of the preferred date (date selected on Appointment Earliest Date Screen) - The earliest date allowed for scheduling is the day after the current day - The latest date allowed for scheduling is 395 days after the current date Note: This may be further limited if the chosen VistA clinic has a max booking date that's less than 395 days. If that's the case, the front end will not receive any slots after this date - Dates that are not eligible for selection should be disabled 6. Verify section 'Choose preferred time of day' is displayed below the calendar 7. Verify radio list option of time slots avail are displayed Format: HH:MM AM or PM Get data from: `Get: /v0/appointments/facilities/{facililty_id}/clinics/{clinic_id}/slots` 8. Verify action button Apply is displayed on the bottom of the screen [Figma Wireframe:DirectCalendar View](https://www.figma.com/file/ZIHY63cFlD7pFjqQLA5rFN/Appointments-Direct-%2B-COVID?node-id=133%3A1384) **Accessibility Requirements** 1. Close AccessibilityHint: 2. Apply AccessibilityHint: General: Standard: 1. Everything on the page should be read by the screen reader. If anything is being conveyed visually only (buttons, menu items, list, tables, images, headings, forms, etc) the component type needs to be announced by the screenreader. (Include name (title), role, value) 2. Each page should support text resizing based on the OS font scaling settings without loss of content, content overlap, or horizontal scroll. Each touch target must be at minimum 44px by 44px 3. All elements on a page should be able to be traversed by an auxiliary keyboard. As a user uses the keyboard to navigate a page, its focus element should be clear. 4. The app needs to support operability by tap (no gestures) or voice control only. In cases where gestures occur, e.g. scroll, ensure these simple gestures are operable through the OS’ built-in capabilities. 5. For all lists with more than 1 option/result, screen reader should specify count of each option as it reads the option ## Notes & Open Questions - Dependencies/Roadblocks: - Any internal/external dependencies? - Test accounts needed? - Does this require QA? - Dev Notes: ## Ticket Checklist - [ ] Acceptance criteria defined - [ ] Labels added (front-end, back-end, feature) - [ ] Linked to an Epic

[bischoffa]

Ticket closed, old ticket. Stale label added. No action taken.