Accessibility: Make sure widget elements are in the proper order for screen readers

[caaster]

Issue Description - WCAG standard

I believe this is the correct reference but my assumption should be double checked: 1.3.2 Meaningful Sequence, requires that the order in which content is presented in the source code should logically match the intended reading order. This ensures that users accessing content through assistive technologies, like screen readers, can understand the information in a coherent and meaningful way.

Method of discovery

Consultation with the Stanford Office of Digital Accessibility (SODA) in June 2025 about alt text for this exhibit page revealed that at least one widget (in this case, Uploaded item row) has elements that are not in the proper reading order for screen readers. We were told at the very least that the heading should be read first by a screen reader, instead of the alt text.

The following research needs to occur:

1. Check every Spotlight widget to make sure the elements are in the proper reading order in the html for screen readers.
2. Verify the WCAG standard: are there widget elements in addition to the heading that should be in a particular order?
3. What happens if an exhibit creator doesn't use the heading or another element in the widget? How does this affect a11y and how can it be mitigated?

Steps to Reproduce

1. Navigate to an exhibit that uses the Uploaded item row widget, such as: https://exhibits.stanford.edu/exemplars/feature/bound-objects
2. Inspect the html, and/or use a screen reader for the page.

Suggested solution

Depends upon the results from the 3 research steps listed above.

[corylown]

I think the crux of the issue here is whether the heading is intended as a heading for BOTH the image and text or if it's just intended as a heading for the text. The current layout would suggest it's intended only as a heading for the text. I think fixing this would change the layout so the heading is above both the image and text and not just above the text. I don't know what the original design intent was.

The position of the heading field in the widget editor (after the image and before the text field) leads me to think that it was intended as a heading for the text only and that a heading intended for BOTH the image and text should be added as a separate heading widget.

The widgets on https://exhibits.stanford.edu/exemplars/feature/bound-objects don't actually illustrate the issue because none of them have headings added.