clickable whitespace

[hackartisan]

looks like this problem crept back into sufia 7.

https://github.com/projecthydra/sufia/issues/1335

[mjgiarlo]

Dang. I suppose it's hard to test clickable whitespace in rspec!

[atz]

It can be done, I think:

expect{ find('.selector').click }.to raise_error(Capybara::Poltergeist::MouseEventFailed)

[atz]

Isn't there a downside of this design when the image is small? Can we solve this with something like a hover effect that makes it clear "clicking here will do something"?

[hackartisan]

There's a download link, too, so if the image is small a person could always use the text link instead. Not sure what sort of small image you'd be storing in one of these systems, though.

[hackartisan]

emoji collection

[mtribone]

Do we need to have both the image and the caption clickable? If we needed the caption because it was unclear to people that they could click the picture to download it, why not just make the caption the only clickable thing?

@projecthydra/sufia-ui-ux-advisors

[hackartisan]

I think we need both to be clickable. Ultimately the thumbnail should open a viewer rather than download, but either way my users definitely expect that to be clickable and find it more convenient than locating the textual link.

[mtribone]

@hackmastera Okay. And we have the "download the full-size image" all over the place. Might be time to refactor this little bit of code. I think we're stretching the intended use of the <figure> and <figcaption> a bit.

[mtribone]

So this is going to be a bit tricky since we have one <a href> wrapping the whole <figure> and the image is no longer scaling with the size of the column. When the image would scale, it would fill up more of the available space.

We could split the <img> and the <figcaption> up and give them each their own <a href>. It is bad practice to have 2 links to the same place right next to each other, BUT it would solve the clickable white space. Hmmmm...

[hackartisan]

+1 to splitting them up.

[mtribone]

@mjgiarlo Want this proposed change in CC or keep it in Sufia? Looking to give the <img> and <figcaption> their own <a href> and might "hide" the image from screen readers.

[front-endian]

-1 for splitting them up. That is a very real accessibility problem and would be especially bad since the links would be right next to one another.

[front-endian]

Can we instead make the width of the box match the content better to remove the large portion of the clickable whitespace and potentially put a light background-color with the whole to make it clearer to users that it is all one group? (maybe with an outline added on focus/hover)

[mtribone]

@justcolin Yeah that was a concern, but wondered if hiding the link around the image from screen readers would get around that issue? I was just playing around with the size of the area as an alternative, but wondered about customization and sentence length.

Also, multiple attributes say the same thing (Download...) over and over again.

[hackartisan]

incidentally why isn't the image scaling up a little bit here? it seems really small. even so, there are use cases where an image doesn't scale the full width and there is still clickable whitespace

[hackartisan]

i'm okay with adding another, narrower container around the image and caption. still what happens though if the image is narrow and the caption is longer than the width of the image?

why is it so bad to have two links with the same target?

[mtribone]

Proof of concept:

[hackartisan]

👎

[hackartisan]

what about a smaller font on the caption, unlink the caption itself and just call it "download"?

[hackartisan]

-1 on centering

[mjgiarlo]

@mtribone :speech_balloon:

@mjgiarlo Want this proposed change in CC or keep it in Sufia?

Where does your fix go? Ideally this would be fixed in both codebases, so if you can fix it in one place (CC) and have that work in Sufia, that'd be ideal.

[mtribone]

1px border

[front-endian]

As far as I am aware there is no way to reliably hide links from assistive technologies. You might be able to finagle ARIA to do it for some, but other assistive technologies will always read out any links that are links.

As for why it is a problem (short version): many assistive technologies offer users a feature to list out all links that are present on a page, and duplicate links clutter that up heavily. It also confuses screen reader users. In other cases it can be okay, but two links going to the same thing right next to one another is a real annoyance and problem for many people using assistive technologies.

[front-endian]

Can we have the width shrink to fit the content using one of those newer CSS attributes? (On a bus, thus I cannot remember the names off the top of my head.)

[front-endian]

Seconding and building on an alternative suggestion which @mtribone brought up before:

Only link the text and make the text look more like a button with maybe a download icon on it so it is a bit more obvious to users. If the image is linked it should link out to an image/video/media viewer, not a download link.

@heidisb: do you think not linking the image and only having the download text bellow the image linked would confuse users?

[hackartisan]

buttonizing it works for me.

[heidisb]

What y'all said. Buttonize the download link text and don't link the image. From a writing for the web (and accessibility) perspective, having a linked image doesn't tell you anything -- no idea where it will take you. Main reason I see to link images is to provide access to a larger/full resolution version.

---

Heidi Steiner Burkhardt | User Experience Specialist | University of Michigan Library heidisb@umich.edu | @heidi_sb

On Thu, Aug 18, 2016 at 3:57 PM, hackmastera notifications@github.com wrote:

buttonizing it works for me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/projecthydra/sufia/issues/2466#issuecomment-240837901, or mute the thread https://github.com/notifications/unsubscribe-auth/ALAvMFH6KKUcJbLhBWcIWcl2cYdi8f3Zks5qhLkggaJpZM4JjXoh .

[bnhowell]

How important is downloading this image content? If this interaction (viewing image) is super regular I would make sure the link size is larger (image). If users are interacting infrequently with the 'download image' text then I agree that only a text link needs to appear. My gut reaction is that users standard expectations are to click a photo to see a larger version of it.

Peace love and understanding y'all.

BTW...Where's the heatmap of this interaction?

On Thu, Aug 18, 2016 at 3:57 PM, hackmastera notifications@github.com wrote:

buttonizing it works for me.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/projecthydra/sufia/issues/2466#issuecomment-240837901, or mute the thread https://github.com/notifications/unsubscribe-auth/AQBqvx1cHU4eL0Vry1RQBrWelFaGPTq5ks5qhLkhgaJpZM4JjXoh .

Ben Howell | Accessibility & User Experience Specialist Design & Discovery | LIT | University of Michigan Library bnhowell@gmail.com

[mtribone]

@justcolin @heidisb @bnhowell Thanks for the feedback!

Based on @hackmastera's feedback, she feels that her users expect that sort of interaction. I am unsure of the importance of the need to download the image, but would like to hear from others about use cases. In the meantime, I'll gist a proposed solution based on ⬆️ for feedback and we'll go from there.

@bnhowell Heat maps?! I wish we had such things and similar techniques to help us make decisions for the greater good of Sufia. Perhaps we can talk about it online and at Hydra Connect?

And yes, peace, love, and understanding! ✌️

[hackartisan]

I would like to back off a bit on my assertion here! I do think users expect that a thumbnail like this will be clickable and my own users have told me this directly. But I also agree that the expected result is a viewer. Therefore if we want to make a download button and disable the clickable-ness of the thumbnail in the meantime I can +1 that.

[mtribone]

So I think this is going to need to happen in two steps because the layout for CC is different than the layout for Sufia. We can address the linking, button-izing, accessibility and such in CC and then make adjustments visually in Sufia.

[mtribone]

If we remove "...the full-sized image" from the button, would users think that they could download the entire work?

[front-endian]

I think it would be clear to users if it were just "Download image"

On Aug 19, 2016, at 10:42 AM, Michael Tribone notifications@github.com wrote:

If we remove "...the full-sized image" from the button, would users think that they could download the entire work?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bnhowell]

+1 for "Download image"

On Fri, Aug 19, 2016 at 11:12 AM, justcolin notifications@github.com wrote:

I think it would be clear to users if it were just "Download image"

On Aug 19, 2016, at 10:42 AM, Michael Tribone notifications@github.com wrote:

If we remove "...the full-sized image" from the button, would users think that they could download the entire work?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/projecthydra/sufia/issues/2466#issuecomment-241045572, or mute the thread https://github.com/notifications/unsubscribe-auth/AQBqv8f739eHfI-YNshP0eCcRQ9f9uamks5qhcfEgaJpZM4JjXoh .

Ben Howell | Accessibility & User Experience Specialist Design & Discovery | LIT | University of Michigan Library bnhowell@gmail.com

[mtribone]

As for the alt text on the image, I am thinking that alt="" is appropriate for the image since there isn't a way to meaningfully describe the image. Or do we stick with the default alt="Thumbnail of filename" ?

[front-endian]

Agreed. alt="" role="presentation" is appropriate unless we want to start requiring uploaders to write alt text.

Note: if the image becomes clickable in the future it will need alt text and to have that role removed.

[mjgiarlo]

@mtribone Are you working on this one, @mtribone? If so, can you remove the Ready label and add the In Progress label? (Trying to get my waffle board in order and want to prevent the stepping-on of toes.)

[bnhowell]

The PhotoAltTextFetcher utility used by Facebook, generates alt text based on several pieces of metadata from the image. More about it here: https://code.facebook.com/posts/727262460626945/under-the-hood-facebook-accessibility/

This would be an interesting path for us. (Not sure how possible this would be for us)

On Fri, Aug 19, 2016 at 1:46 PM, Michael J. Giarlo <notifications@github.com

wrote:

@mtribone https://github.com/mtribone Are you working on this one, @mtribone https://github.com/mtribone? If so, can you remove the Ready label and add the In Progress label? (Trying to get my waffle board in order and want to prevent the stepping-on of toes.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/projecthydra/sufia/issues/2466#issuecomment-241085992, or mute the thread https://github.com/notifications/unsubscribe-auth/AQBqv292jHIjvCmtpJld2CmpqZvH66SGks5qhevdgaJpZM4JjXoh .

Ben Howell | Accessibility & User Experience Specialist Design & Discovery | LIT | University of Michigan Library bnhowell@gmail.com

[front-endian]

@bnhowell: I was just talking with a blind individual at a conference about Facebook's image alt text stuff. We both were in agreement that—though interesting—the usefulness of a lot of there stuff is limited. Some of it isn't guaranteed to be accurate (this is why automated video captioning doesn't count as captioning for the WCAG 2.0 guidelines), and often doesn't provide relevant information. They have played around with image recognition, but hearing that an image contains "20 individuals, 3 seated" isn't that useful because they can't figure out why the image relevant and what features are contextually important.

[mtribone]

Can I get some 👀 on my approach to resolve the clickable white space and accessibility?

https://github.com/projecthydra/curation_concerns/pull/927/files

[front-endian]

@mtribone: looking at it now.