Closed mtribone closed 6 years ago
Heads-up, @samvera/hyrax-ui-ux-advisors
@mtribone- These seems a more intelligent solution than reading the filename - but will it still pass automated accessibility scanners? Will a scanner see the metadata next to the thumbnail or expect that to be in an alt tag?
@newmanld This will pass an automated scan because we are still keeping the alt
attribute present. We are just keeping it empty. For example, alt=""
will be picked up as being present in a scan but won't distract or confuse users with a value that doesn't describe the content or functionality.
Thanks @mtribone. FYI, we will be in the next 30 days against our app on Hyrax 1.x, running a commercial accessibility scanner that our central campus IT department has licensed, and we'll let the community know any findings that point to Hyrax and not our app.
@mtribone - definitely way out of my comfort zone here (i.e. my specific expertise), but these sentences on webaim seem to say that an empty alt tag is ok if explanatory text is within the same link as an image, but not if the text is merely adjacent? "If an image is the only thing within a link or if it's a button, it must have adequate alternative text to provide users what the link or button will do if activated. This is true even if that alternative text is the same as adjacent text. <...> the best solution is to simply combine the image and the text into one link and give the image empty alt text (alt="") because the text now adequately provides the alternative for the image AND the functionality of the link." http://webaim.org/articles/gonewild/.
@newmanld I'm no expert either and I think that you make a great point.
The reasons why I want to treat the thumbnail like a decorative element are because:
the title is linked and goes to the same page via a search result or the fieldset page
on show pages we use role="presentation"
for the thumbnail
I question whether or not the title of a work accurately or consistently, throughout the system, describes the content of the thumbnail if we put the thumbnail inside of the linked title–especially if we can pick our representative image.
So I punt and hide it and set the alt attribute to "" as a backup in case a particular version of assistive technology ignores me hiding it. We can certainly explore this further and I'm open to the method that you've pointed out. Great feedback Linda!
Sorry to butt in, but I think this one is worth rethinking.
I'm looking at Hyrax 2.1.0 beta 2 and if I'm understanding what I'm seeing, the thumbnails need a fix of some kind. If an image is the only item in a link, it must have a non-null alt attribute. Per WCAG and Webaim, "An image that is the only thing inside a link must never have a missing or null alt attribute."
The problem with just using aria-hidden="true"
is that it's still in the tab order, so the screen reader won't announce it, but will still tab to it. This is obviously confusing, as the user isn't sure what happened when hitting "tab" to get to the link. And this can be especially confusing for screen-reader users who have some sight, which is reportedly a larger group than SR users with no sight at all.
You could use JS to pull it out of the tab order, but then you're adding using ARIA and JS to an element that never needed either. And if the JS is happening behind the scenes (e.g., just selecting everything with aria-hidden and pulling it out of the tab order), then we're talking about an added point of failure and magic behaviors that accessibility-minded devs won't understand without a lot of digging.
@newmanld explained the options best, but I think they're worth repeating:
@jechols No need to apologize! This one definitely needs rethinking because it is a complex issue. This one was ported from Sufia and was intended at first to be an interim solution, so that the file name wasn't read out loud. Wrapping the thumbnail and the linked title IS the solution, but at the time the push back was that it "seemed like a lot of work" and "had to be done in multiple places."
I don't think that having the alt text the same as the title is the best option. It's an easy option, just like attempting to hide it as a decorative image, but we then have adjacent links with the same text that go to the same place. It might check the box for the WCAG, but does that mean that it is usable? I don't know. However both you and @newmanld have the correct answer, so let's push for it!
Just re-iterating for the upcoming accessibility work based on the report from the consultancy and the above conversation. We have 2 adjacent links that go to the same content. One is the thumbnail image and the other is the title of the work or collection.
The recommendation is to combine the thumbnail and the title of the work or collection, so that they are in the same hyperlink.
These can be found on the home page for the Featured Works, Recently Uploaded, and Explore Collections.
@dlpierce Just double checking that you've seen the discussion in this thread for success criteria as my original ticket is out-of-date. The recommendation is to combine the thumbnail and the title of the work or collection, so that they are in the same hyperlink.
Descriptive summary
In Hyrax 2.0.0 alpha the rails default for the image tag helper uses the name of the file as the
alt
attribute. We should make thealt
attribute empty and addaria-hidden=true
for better accessibility.Rationale
People who use assistive technology would hear the file name read aloud for the image and the filename isn't in an understandable form when better metadata in everyday language is right next to the thumbnail. We can set the thumbnail to empty and hide it from certain screen readers by additionally using
aria-hidden=true
.http://webaim.org/techniques/alttext/#conclusion
Expected behavior
Screen readers would skip right over
alt
attribute that doesn't contain actionable or descriptivealt
attribute.Actual behavior
File name is read aloud using assistive technology.
Steps to reproduce the behavior
Related work
https://github.com/psu-stewardship/scholarsphere/pull/498