Request Appointment- Create UI screen for Type of Care Sub Type

[MekoHong]

Description

As a Veteran, I want to select a specific care type when scheduling in appointment for my eye, sleep, or audiology care, so that the scheduler knows what type of appointment that I need and they are schedule the appointment accordingly.

As part of this story we want to:

• Create a new UI screen for Type of Care Sub type that will be required when selecting Service Types
  • Eye care
  • Sleep medicine
  • Audiology and speech (including hearing aid support)

Data Schema

API Docs: https://department-of-veterans-affairs.github.io/va-mobile-app/api/#operation/CreateNewAppointment

Field name: serviceType

Eye Care

Values:

[
  {
    "label": "Optometry",
    "value": "optometry"
  },
  {
    "label": "Ophthalmology",
    "value": "ophthalmology"
  }
]

Audiology

Values:

[
  {
    "label": "Routine hearing exam",
    "value": "audiology-routine exam"
  },
  {
    "label": "Hearing aid support",
    "value": "audiology-hearing aid support"
  }
]

Sleep

Values:

[
  {
    "label": "Continuous Positive Airway Pressure (CPAP)",
    "value": "cpap"
  },
  {
    "label": "Sleep medicine and home sleep testing",
    "value": "homeSleepTesting"
  }
]

Acceptance Criteria

1. - [ ] Create a UI screen 'Type of Care Sub Type' 2. - [ ] Verify header text reads 'Which type of [type of care] do you need? **When** Type of care previously selected = Eye Care, Sleep medicine, or Audiology and Speech. - Note: Text should say "Eye care", "Sleep medicine care", or "Audiology and Speech care". [Type of care] will be dynamic based on the type of care selected (this requirement will be part of future ticket) 3. - [ ] Verify Close is displayed at the top left corner of the page 4. - [ ] Verify help icon '?' is displayed at the top right corner of the page 5. - [ ] Verify the Care Type option list uses the radio button list component 6. - [ ] The list option(s) shown will be dynamic based on Type of Care previously selected Options will be a. Optometry & Ophthalmology when type of care selected = Eye care b. Continuous Positive Airway Pressure (CPAP) & Sleep medicine and home sleep testing when type of care selected = Sleep medicine c. Routine hearing exam & Hearing aid support when type of care selected = Audiology & Speech 7. - [ ] Verify text 'Need help choosing? with an expand/collapsable option is displayed at the bottom of the page above the Back and Continue buttons 8. - [ ] Verify buttons Back & Continue are displayed on the bottom of the page **Wireframe** [Type of Care Sub Type](https://www.sketch.com/s/806417fd-3d64-4da6-9529-0eef4fd48e2e/a/OmAQDwv) **Accessibility Requirements** A11y Hint requirements 1. Cancel AccessibilityHint: Cancel Appointment request 2. Help icon - AccessibilityHint: Get scheduling help 3. Continue Button - AccessibilityHint: Navigate to the next page 4. Back Button - AccessibilityHint: Navigate to the previous page 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. 3. Each touch target must be at minimum 44px by 44px 4. 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. 5. 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. 6. Cancel 7. Help icon ? ## Notes & Open Questions - Dependencies/Roadblocks: - Any internal/external dependencies? - Test accounts needed? - Does this require QA? - Dev Notes: ## Ticket Checklist - [X] Acceptance criteria defined - [X] Labels added (front-end, back-end, feature) - [X] Linked to an Epic

[TKDickson]

Test run 3461 created to test this (same test run as the subtype help modal)

[MekoHong]

Closing ticket, feature not being currently worked and due to lapse in time it was decided to close all scheduling tickets. No testing of tickets and will revisit in future