tkakar/cat-1029-fix-links-for-accessibility #3620
Conversation
| return <a href={href}>{tile}</a>; | ||
| return ( | ||
| <a href={href} aria-label={href}> | ||
| {tile} |
There was a problem hiding this comment.
Not sure if we want to parse the hrefs in this case by extracting keywords from them. But it would need some kind of mapping, easy for organs, difficult for datasets page with long uuids that are not meaningful
There was a problem hiding this comment.
Ditto here - I think constructing a descriptive text would be more straightforward if we were to define that logic from the parent element that uses these tiles.
| } | ||
|
|
||
| const decodedHref = JSON.parse(LZString.decompressFromEncodedURIComponent(encodedURI)) as searchObj; | ||
|
|
There was a problem hiding this comment.
I took a first pass on this, this extracts the filter (assaytype, etc) and organ, we can also include the count (shown on hover) but not sure if that's important as hover does provide that info?
Also, would be happy to move it to some utils file, or adding more meaningful content to the aria-label
There was a problem hiding this comment.
Perhaps we could pass the aria-label text generation logic to the stacked bar chart, then directly pass the label as a prop here? That seems simpler than reverse engineering the aria label from the href, and will work for non-search page links as well.
tkakar
changed the title
| @@ -97,6 +97,7 @@ function Tile({ hit }: { hit: SearchHit<Partial<Entity>> }) { | |||
| uuid={hit?._source?.uuid} | |||
| id={hit?._source?.hubmap_id} | |||
| entityData={hit?._source} | |||
| ariaLabelText={`Tile representing ${hit?._source?.entity_type} ${hit?._source?.uuid}`} | |||
There was a problem hiding this comment.
I think the HBM ID would be preferable to the UUID here since the screenreader would have to read off all 32 characters of the UUID.
We may also want to be more descriptive depending on the result type - e.g. right now this will say Tile representing Dataset blahblahblah or Tile representing Sample blahblahblah, but in the future we could provide e.g. the assay type and source organ for datasets, sample category and source organ for samples, and descriptive info for donors.
| @@ -92,6 +92,7 @@ function ProvEntityColumnContent({ | |||
| uuid={item.uuid} | |||
| id={item.hubmap_id} | |||
| entity_type={item.entity_type} | |||
| ariaLabelText={`Tile representing ${item.entity_type} ${item.uuid}`} | |||
There was a problem hiding this comment.
I wonder if a useEntityTileAriaLabel hook could help? That would allow us to implement more complex logic depending on the content type (dataset/sample/donor).
Similar concern as below with using UUID vs. HBM ID in aria labels.
context/app/static/js/components/detailPage/provenance/ProvTable/ProvTable.tsx
Show resolved
Hide resolved
| const organ = String(d?.bar?.data?.organ); | ||
| const assay = d.key; | ||
| const count = d.key ? d?.bar?.data[d.key] : null; | ||
| return `${count} ${organ} datasets with assay type ${assay}.`; |
There was a problem hiding this comment.
We should account for null's and undefined's string representations in template strings being "null"/"undefined" e.g.:
const test = `${null} ${"Stomach"} datasets with assay type ${"scRNA-seq"}`
console.log(test)
> "null Stomach datasets with assay type scRNA-seq"
const test2 = `${undefined} ${"Stomach"} datasets with assay type ${"scRNA-seq"}`
console.log(test2)
> "undefined Stomach datasets with assay type scRNA-seq"Maybe this could work?
// We can use optional chaining with indexed objects like this:
const count = d?.bar?.data?.[d.key];
if (count) {
return `${count} ${organ} datasets with assay type ${assay}.`;
}
return `${organ} datasets with assay type ${assay}.`
Summary
This PR addresses the accessibility issue of
Ensuring links having discernible textby adding aria-labels to any links used in the code base, particularly, the tiles and stacked barchart components.Design Documentation/Original Tickets
CAT-1029
Testing
Manually tested with Axe DevTools
Screenshots/Video
Include screenshots or video demonstrating any significant visual or behavioral changes.
Checklist
CHANGELOG-your-feature-name-here.mdis present in the root directory, describing the change(s) in full sentences.Additional Notes
Please specify any additional information or context relevant to this PR.