Skip to content

BUG - sev-2 - Probably all? Definitely iOS - Some links in appeals not announcing as links to screenreader #9800

Open
@TKDickson

Description

@TKDickson

What happened?

On at least one link in the mobile app ("opt in to the new decision review process" for an active appeal with a type of pending_form9), but I'm willing to bet a few more beyond that, we are not announcing the link as a link to screen reader users. Here's a video of it in iOS (the only reason I double-tapped on the link was to show that it IS in fact a link, even though it's not announced as one, not because we could reasonably expect screen reader users to do so)

We read the content of the link, and that's it. So screen reader users won't/can't know that the link is a link, and therefore actionable, and do whatever the link is about (in this case, it's one of the MAIN actions they could do for an appeal in this status)

I don't 100% know what's causing this in code, but there are several MobileBodyLink instances in the AppealCurrentStatus file that are at least suspicious-looking, to me, so I'd be willing to bet they are also impacted.

Specs:

  • Device:
  • OS:
  • User Account:
  • Accessibility State:

Steps to Reproduce

  • Will need to have an active appeal with a type of pending_form9, or use Charles Proxy to mock one
  • Log in as a user with screen reader on, and navigate to ^ appeal
  • Swipe through the whole screen, notice the "opt in to the new decision review process" bullet point link is not announced as a link

Desired behavior

All links should be announced with a role of 'link'

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See Bug Tracking for details on severity levels

  • Impact: High
  • Frequency: Low
  • 2 - High

Linked to Story

Found while testing, but not caused by, #5779

Screen shot(s) and additional information

Full JSON response for services related to issue (expand/collapse)

for any appeals details response:

{
	"data": {
		"id": "A1116",
		"type": "appeal",
		"attributes": {
			"appealIds": ["A1116"],
			"active": true,
			"alerts": [],
			"aod": false,
			"aoj": "vba",
			"description": "Tinnitus",
			"docket": {},
			"events": [{
				"type": "ama_nod",
				"date": "2023-02-17"
			}, {
				"type": "distributed_to_vlj",
				"date": "2024-02-15"
			}],
			"evidence": [],
			"incompleteHistory": false,
			"issues": [{
				"active": true,
				"lastAction": null,
				"description": "Tinnitus",
				"diagnosticCode": "6260",
				"date": null
			}],
			"location": "bva",
			"programArea": "compensation",
			"status": {
				"type": "pending_form9",
				"details": {}
			},
			"type": "appeal",
			"updated": "2024-11-17T22:49:53-05:00"
		}
	}
}

Ticket Checklist

  • Steps to reproduce are defined
  • Desired behavior is added
  • Labels added (front-end, back-end, global, Health, relevant feature, accessibility, etc)
  • Estimate of 1 added (for front-end tickets)
  • Added either to the relevant feature epic (if found during new feature implementation), or the relevant team's bug epic (Global, Health & Benefits, API, QART)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    HealthTickets are tied to the Health Product Team PmsQATickets require QA work / reviewaccessibilityAccessibility awareness or needs for the ticketbugUsed to identify a bug ticket that will be worked through the bug processclaims & appealsfront-endTicket requires front-end worksev-2Mid-tier bug severity level based on QA bug severity scale - QA to assign this

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions