Safe content browsing flow

[fcoveram]

Problem

The current browsing experience hides content marked as mature to allow a safe experience when displaying results. However, and as defined in project #377, we decided to allow visitors to opt-in browsing and seeing results marked as sensitive.

Issues related

Project #377

• User stories stated as “As an Openverse user”: #362
• Blurring single results: #505
• Sensitive content filter: #2153

PR

• 824

Proposal

Before diving into details, here is a flow for the search results and landing in a single result in both xl and xs breakpoints.

Search results

xl breakpoint

https://user-images.githubusercontent.com/895819/221883944-a9111e27-d220-40fe-8e35-d4d57b51208f.mp4

xs breakpoint

https://user-images.githubusercontent.com/895819/221884009-31f84839-9fdb-45aa-8dd4-86db06677db4.mp4

Single result page

xl breakpoint

https://user-images.githubusercontent.com/895819/221884291-2690270d-b1d2-46a5-ae22-58976a828188.mp4

xs breakpoint

https://user-images.githubusercontent.com/895819/221884311-4c28b45b-89dd-4b0c-97e0-d3ef35062913.mp4

Description

Opt-in settings in footer

Even when the safe browsing settings do narrow the results, placing the toggles in the filter sidebar felt without much context during the prototype tests. Because of that, and since browsing mode sets a site-wise experience, putting the component out of the filter section made more sense.

This design proposes updating the footer again. I acknowledge the efforts of simplifying this component, but this design goes further in simplicity by reducing its height and making the WordPress mention more simple. The idea is open to discussion so please leave your thoughts.

On small devices, the popover behaves as a modal. Same as other modals but revamping it with updated styles.

Having this component in the footer would also allow us to add other opt-in settings like privacy and, in the future, replace the area with a user settings one once we start exploring the collection feature. Note the exploration below.

Blurring page

As noted in the user stories (#362), the single result page blurs all content area with white at 80% plus a noise texture as it keeps the header and footer clean. The CTA area is fixed in the center, and the Go to search button takes you to the homepage. I kept the page height to avoid hiding the footer as some visitors might want to click on any of those links or change the site language.

As discussed in other tickets, the switcher and filters are disabled, and "back to results" action is not visible as no search term was applied.

You can find below a version that only blurs the image area, in case we want to take that path.

---

Feedback

What do you think of this idea? Please share all your thoughts

Mockups

Figma: Content safety browsing flow.

[openverse-bot]

Subscribe to Label Action

cc @WordPress/gutenberg-design, @WordPress/openverse

This issue or pull request has been labeled: "🖼️ aspect: design" Thus the following users have been cc'd because of the following labels: * WordPress/gutenberg-design: 🖼️ aspect: design * WordPress/openverse: 🖼️ aspect: design To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file. [Learn more.](https://github.com/bytecodealliance/subscribe-to-label-action)

[estelaris]

I feel like the icon is not making sense in the footer. The component out of the filter area and the functionality are great but the gear icon doesn't tell "here you can change the browsing options".

There are "browsing settings" and "browsing options", I don't think that _blurring sensitive _content__ should be treated as a setting but as an option, the user chooses to see/not see sensitive content and when.

[zackkrida]

This is awesome. There are so many great refinements here. I'll split up my thoughts into sections:

Single results

I love the look of the blur here with the 80% opacity white.

In the future, we hope to have specific reasons why an image was marked as sensitive, for example:

This image has been marked as sensitive by our community with the following labels:

• Violence/Gore

For the first version of this blurring, I think the approach you've shared is perfect.

The "hide content" button is also a very nice detail, as it lets someone change their mind quickly without leaving Openverse.

Search results

I like the solution for the two toggles. I would propose the following copy for those:

• Include sensitive content
• Blur sensitive results

The second checkbox, "blur sensitive results", should be enabled by default.

The actual blur looks good. I like the amount of blur and the amount of the image which remains.

Safe browsing placement

The footer doesn't feel right to me for the placement of these settings. I definitely understand the motivation for putting it there and what would draw you to that choice. It isn't exactly a filter:

1. The sensitive content setting should be persistient, saved locally in the browser so the user's preference is preserved. The other filters are reset per-search.
2. We may have other account/general settings in the future.

For a few reasons, I would prefer that we keep the "Safe browsing" section in the filter sidebar:

1. The filter sidebar is where users expect to modify the results they are seeing. The only other place users do this is in the header, with the content switcher. Adding a third place, the footer, feels unnatural.
2. I think the feature has more visibility in the filters sidebar, and might be used more there.
3. We just redesigned the footer, and adding it to the sidebar would be an easy win.

I think making a big change to the placement of these settings will be a big project. It also relates to a few other initiatives. What, for example, if we add sorting in the future?

I could see these settings living in the sidebar, for now, but duplicated in a user settings popup in the future, like the design you showed.

[joedolson]

Here are some accessibility comments:

Multiple result view

1) The state of the 'Show sensitive content' and 'show blurred results' is ambiguous. I was not able to tell visually whether the filter was enabled or disabled. This style of toggle shouldn't be used for features where the result may be important for safety reasons and a change of state may not result in any change in the content. E.g., if there are no sensitive results in the current result set, toggling that control does not change anything, and there is no way to tell visually whether you have it turned on or not.

2) The blur amount seems insufficient to me. For close up images, e.g. the starfish in the example video, it is quite obvious what is in the picture even while blurred. This is probably a very subjective condition however, and may not be solvable in a way that's useful.

3) Why is the toggle text different on the mobile breakpoint from the desktop breakpoint? Show "mature" content does not mean the same thing as "sensitive" content, and these are not interchangeable. The language used on the toggle needs to be clear.

4) It's possible that "sensitive" alone is not sufficiently discrete. E.g., images of violence and other sensitive media are not the same as images of nudity and sexuality, and a user may well need to filter one out without filtering out both.

Single item view

5) I don't think that the page should be scrollable while the sensitive content overlay is in place. The only visible content is the overlay and the footer, and there's no reason to be able to manipulate the rest of the content. This also makes me concerned that the hidden content would still be accessible to screen readers & keyboard navigation even though it's hidden, which it shouldn't be.

6) It's not clear from context whether this overlay only appears when the blur filter is in place; could use some context for when this overlay would appear.

7) Again, need more context. Knowing that an image is marked as "sensitive" is insufficient information. Content warnings should come with specific information about the type of content contained.

8) In the example which shows blurring only the image, should also take into consideration needing to hide image descriptions, as those could incorporate sensitive language that also needs to be hidden. (None of the examples include a visible description of the image, and I don't know whether that's ever part of this interface, but if it is, it also needs to be considered.)

[zackkrida]

I definitely agree long-term with @joedolson that we'd like to give a specific content label when explaining why an image is marked sensitive. I do not think we'll have that information initially, on the first pass of this feature.

As a solution while we build those specific content labels, could we link the "marked as sensitive" label to a page where we explain sensitive content?

[afercia]

I feel like the icon is not making sense in the footer ... the gear icon doesn't tell "here you can change the browsing options".

I'd agree. I do understand that in the future this component will likely contain additional settings but, for now, it only contains the Safe Browsing settings. I'm not sure the gear icon is appropriate for that. Moreover, from an accessibility perspective, icons should be avoided and only be used when there's no space in the UI to use visible text. Using an icon is already a compromise in terms of accessibility.

Re: placement in the footer: I'm not sure that's the ideal place. A footer is meant to be used tor ancillary information e.g. copyright, privacy, about us and the like. It's not a place for functionality. In this specific case there are two more considerations:

• In the tab sequence, the filters sidebar comes first. Then, there's the content area. Finallly, there's the footer. As such, the Safe Browsing settings are placed in a spot that is dozens of tab key presses far from the filters. Loading more images in teh grid makes the Safe Browsing settings even less reachable.
• The footer may be initially out of view, which makes the Safe Browsing settings less than discoverable.

Having this component in the footer would also allow us to add other opt-in settings like privacy and, in the future, replace the area with a user settings one once we start exploring the collection feature.

GivenI get this is going to evolve in a 'User settings popover' that contains preferences and account settings:

The popover button will also use the user's avatar. As such, I'd like to suggest to place this component in the top right of the screen. Most (all?) of the web applications I can think of place the User/Account settings there. Users are familiar with that pattern and the placement at the top right would also solve some of the issues mentioned above.

[fcoveram]

Thanks for all your thoughts ✨ I will summarize the suggestions to iterate on the idea and address your points.

Conveying the feature

Replace the gear icon with a component that prioritizes text information.

Setting position

Moving the action out of the footer as it is not reachable and lacks of context. I will explore a version in the sidebar where it fits better with modifying the results.

The sensitive content setting should be persistient, saved locally in the browser so the user's preference is preserved. The other filters are reset per-search.

To the point mentioned above by @zackkrida, I wonder how clearing filters could work then. There is a risk of resetting the options selected and showing up unsolicited content in the results area when visitors want to clear the sources chosen.

A solution to this could be putting apart this setting from the “clear” action, and adding a separator that splits the sidebar into two separated areas. For the tab navigation point mentioned by @afercia, placing the setting between filters and the content area will make it more reachable.

Action labels

The second checkbox, "blur sensitive results", should be enabled by default.

To your point @zackkrida, I tested different ways of describing the action. Since the first toggle is disabled and hides content by default, the enable state shows more content. For the blur toggle, I followed the same logic: the disabled state hides content while the enable state shows the content (by removing the blur effect.)

The flow of enabling the 1st action to then disable the 2nd one felt odd in the prototype test. I can make a quick video showing the interaction.

In that vein, when @joedolson says

…images of violence and other sensitive media are not the same as images of nudity and sexuality, and a user may well need to filter one out without filtering out both.

It makes sense to me to enable one feature after another to show up more content.

Sensitive content reason

I will explore another solution to communicate more clearly why this content is hidden. I like @zackkrida’s idea of linking to a rationale page explaining the reason behind this while we build the content labels.

Hidden content effect

• I will explore another solution for the blur effect in the result area.
• I will move away from the scrollable page idea.

---

Question

To @joedolson’s point

This style of toggle shouldn't be used for features where the result may be important for safety reasons and a change of state may not result in any change in the content. E.g., if there are no sensitive results in the current result set, toggling that control does not change anything, and there is no way to tell visually whether you have it turned on or not.

Which interaction do you think suits better for this kind of setting? I can only think of adding an interaction layer to confirm the change.

[joedolson]

Re: interaction.

Any user interface component that has a clear 'on' and 'off' state. E.g., a checkbox is clearly selected or not selected: it either has a check or it does not have a check. A toggle like this is ambiguous. How are you supposed to know whether left or right is 'on', or whether a light dot on a dark background means 'on' or 'off'?

[joedolson]

An additional note on having a clear on and off state - Yoast does this well in their settings, by changing the icon within the toggle from a check to an x based on state; this is a more clear visual cue.

[jasmussen]

I would hate for Openverse to diverge from Gutenberg as far as the componentry goes. Ultimately they are all WordPress core related projects. In the case of Gutenberg, we actually tried on/off helpers, inspired by the iOS toggle you can flip to enable those. Little I/O icons for on/off. It turned out to be noisy in cases of multiple controls side by side, with the more complicated silhouette, so we ended up reverting that. What's a visual aid for some becomes stressful noise for others, especially dyslexics.

In that light, I'd keep the toggle sans additional iconography, for consistency with core. However, for both OV and Gutenberg, and similar to how iOS handles it, I would welcome a toggle in preferences that let you choose whether to have this extra iconography present or not, just like we have one for text labels instead of icons.

[fcoveram]

Thanks for sharing that learning @jasmussen. Very fruitful.

I very much agree with a single approach for all WordPress projects. The idea of adding a setting for reinforcing actions through iconography is great. Thanks for that. I will write it down for future improvement.

[fcoveram]

Iteration 2 (i2)

Search results

Here is a new idea based on the feedback shared.

Browsing settings in sidebar

The settings area is now part of the sidebar and works separately from the filters. Therefore, the Clear filters action does not modify these settings, and the "Filter" button does not show any number on big breakpoints nor the dot indicator on small breakpoints.

All texts are open to change, so please share your thoughts about the copy. Once we land on an agreed version, I will ping comms folks asking for review.

xl breakpoint

https://user-images.githubusercontent.com/895819/223690356-3c6d9111-8f7f-4b53-8390-6987e8ae8fb5.mp4

xs breakpoint

https://user-images.githubusercontent.com/895819/223690395-32b8904f-f3cf-4b6a-a1b9-7712271bbcb1.mp4

[zackkrida]

This addresses my concerns and looks great. I can see how the increased blur is definitely an improvement. The copy looks good to me, with one small edit. I would change the "blurred" in the description to "blur" (the verb). "Blurred" in the title is fine.

One missing thing I noticed: Would the blurred images have the CC licenses shown in their hover state the same way non-blurred images do?

[fcoveram]

Iteration 2 (i2)

Before describing the single result iteration, I respond to @zackkrida comments

Would the blurred images have the CC licenses shown in their hover state the same way non-blurred images do?

Yes. I forgot to show that interaction in the video attached.

I would change the "blurred" in the description to "blur" (the verb). "Blurred" in the title is fine.

Sure. Thanks for the suggestion.

---

Single result page

For this page, the following changes were applied:

1. The page content blurred in the background was replaced with a subtle gradient effect filling the viewport size. In xl breakpoint, the height fills the remaining area left by header and footer sizes. Whereas in xs, the area has a min-height to prevent compressing the info and reduce its hierarchy importance.
2. As mentioned before, we will keep the Sensitive content term and add content labels in the future to point out the content category more accurately. In this case, "read more" label will link to a page that details what is the Sensitive content about.

xl breakpoint

https://user-images.githubusercontent.com/895819/223981266-95b5962a-bb57-473f-b0bb-565992fefdba.mp4

xs breakpoint

https://user-images.githubusercontent.com/895819/223981330-472bb023-1f59-46f0-bd07-564a81ae5a02.mp4

[fcoveram]

Blocking this design ticket as waiting for its container project (#377) to discuss and document the project scope and, by consequence, the design outcomes required.

[fcoveram]

Unblocking this ticket as the Project Proposal (#873) is done and design stage needs to conclude to hand-off the assets for the Implementation plan (#938). Pinging @WordPress/openverse-maintainers to ask for feedback on iteration 2 proposals shared above here and here.

These versions are updated with the last comments shared before, and include the conditions stated in the Project Proposal. I hope I did not miss something.

[AetherUnbound]

I don't have any critiques, only chiming in to say this looks fantastic!!

[sarayourfriend]

Excellent work, Francisco, both in the solutions you've iterated on and in managing the feedback thus far!

I don't have any additional concerns about the design. All the ones I had have been raised by others and resolved or explained and tabled for addressing in the future. I have two suggestions and two questions. Neither question is a blocker for this specific solution, but I do think we need to address them before implementing this. Preferably in separate, specific issues for each question. I do think each of them warrants careful consideration. Neither suggestion needs to be implemented in this initial phase, but I think they're relatively easy wins that could be done immediately after the first pass.

This is already an improvement on the previous solution we employed for sensitive results and I don't think moving forward with this (provided we address the accessibility and audio questions) will cause harm to users who explicitly opt-in to including sensitive results.

Suggestions for initial or fast-follow improvements to copy

I have two suggestions for how we could improve the copy on the single results page. I think we have slightly more information about individual result sensitivity than is being considered here. If we cannot do this now, due to time limitations for finding the required provider materials for the copy, I think it's something we could do much sooner than the specific categories of sensitivity already discussed. In any case, based on the project proposal, we will know if individual results are marked "mature" by the provider[^mature], have sensitive terms in the textual content, or both. That means we could update the copy to say a combination of the following and already give more information:

• "The source for this work has marked its contents as sensitive"
• "Openverse has detected potentially sensitive textual content"[^sensitive-textual-content]

Because we know both of these separately, we can combine them in something like: 'The source for this work has marked its contents as sensitive. Additionally, Openverse has detected potentially sensitive textual content'. In the future we can disambiguate what specific category of sensitive textual content we detected.

The other suggestion is to allow revealing the title. Once we're able to note which specific fields and categories of terms the sensitive text appears in, we could automatically reveal the title when the sensitive terms are not in the title. For now, however, at least allowing the user to reveal the title gives them a safer way of finding any hint to what the image content might be.

Questions

I have a couple outstanding questions.

Audio

This solution works for image results. How would this work for audio results? There are, of course, different needs with audio. Audio works have the audio itself (inside of which we cannot detect sensitive content), the textual materials, and the artwork. Are we explicitly putting off solving the same issue for audio until later? If so, that's fine, but then I think we should do the following:

1. Update any description/text about this particular solution to make it clear it is only for image results.
2. Update the project proposal to make it clear that the initial frontend implementation will only be for image results.
   • From the API perspective, there's not much we need to do here.
3. Decide how the filters work in the all results view. In particular, how the text appears, to make it clear that sensitive audio results might be included or that we're filtering them differently (if indeed we are).

Mixing this experience would probably be confusing from a user perspective, however. I would be very confused if I was on the all results view and had included sensitive results in my query and there were images blurred, but there were audio files with, e.g., slurs in the title. Especially if the images blurred were not themselves sensitive but only had sensitive textual content.

Accessibility

I want to reiterate something that @joedolson mentioned regarding screen-readers and give a specific example for where we need to consider precisely how to manage the experience. When a screen-reader navigates the search results, each work's title is read out to them. If a work has been marked as having potentially sensitive textual content—to restate what is above, we do know whether the sensitivity is provider supplied or from our sensitive terms matching—should we replace the link title for that work? Only sighted users have the advantage of the "hint" that the blurred image gives. Users relying on screen-readers probably need additional context to indicate that the specific work may be sensitive. If we know the textual content in particular has sensitive terms, then we probably also need to devise an interaction to give that context specifically on the search results page.

I don't know the best way to manage that interaction, however, and would suggest we enlist the help of someone who could help us better understand the experience and give advice on potential solutions.

[^mature]: I'm using the word "mature" here specifically as it is the word in the database used to encode when the provider has marked a work as such. I don't know that all providers use this terminology, so I stuck to the term "sensitive" in the suggested copy. It's broader and captures the inclusive level of safety we're trying to achieve.

[^sensitive-textual-content]: Is it necessary to note the fact that the sensitive terms may be in the description, which we do not show in the UI nor reveal in the API results? If a work, once revealed, looks really normal and has no sensitive tags or title and the work itself is not sensitive, it could probably be confusing to users. On the other hand, we could exclude the description from this. However, I think that would be a mistake in that we'd probably get a lot more false-negatives in that case and are sacrificing the biggest block of textual hints we have for whether a work includes "sensitive" content.

[sarayourfriend]

Oops, I have one more question: the project proposal mentions being able to blur and reblur results from the search results page. I can't tell if the solutions described here include those, but it isn't in the videos shared (unless I missed it). I think this is also something that we can iterate on or cut from the project proposal but that either way we need to do so explicitly. If we still want to do it, we can implement it at a later date, keeping in mind it will require special consideration for keyboard interactions, but we should note that it is deferred in the project proposal. If we no longer wish to do it (it might be an overly complex interaction or be of low value), then we should also note that we cut that aspect in the project proposal.

[fcoveram]

Thanks for commenting Sara. You shared great thoughts.

Suggestions for initial or fast-follow improvements to copy

• "The source for this work has marked its contents as sensitive"
• "Openverse has detected potentially sensitive textual content"
• “The source for this work has marked its contents as sensitive. Additionally, Openverse has detected potentially sensitive textual content”

_{Note: The third point was taken from another paragraph in the same comment and added to the list by me.}

This suggestion makes total sense to me. Same with your point about matching the sensitive disclaimer and the page content. Otherwise, the warning context would confuse people.

The design change is very easy to make, so the note sounds more like documenting the implementation plan or any other dev input to include these different disclaimer messages.

Once we're able to note which specific fields and categories of terms the sensitive text appears in, we could automatically reveal the title when the sensitive terms are not in the title

Not sure about this idea. I did a quick search for “cat” and the first eight results are titled “cat”, except for one that is “Cat bliss”. Showing the title sounds more useful for audio results where the sentence might collect more info what the audio is about.

Questions

Audio

I completely missed audio in this proposal, and that might have happened because my first explorations were only about blurring images.

Given the impact that this project has on the user experience, I think we should tackle audio case now and not wait until releasing the image browsing. I would appreciate participant folks sharing similar cases from other products that add a safety layer to text and audio results.

Accessibility

If a work has been marked as having potentially sensitive textual content—to restate what is above, we do know whether the sensitivity is provider supplied or from our sensitive terms matching—should we replace the link title for that work? Only sighted users have the advantage of the "hint" that the blurred image gives

I agree with this. And would like to hear what other folks think.

In that vein, and out of curiosity, does it make more sense for screen readers to read the alt text instead? If it exists in the image indeed. But asking this as the alt text describes what’s in the image while the title doesn’t necessarily need to.

[zackkrida]

@joedolson any suggestions for this sensitive content concern? If an image or audio file is marked as sensitive, and the title may contain sensitive/profane words, should we replace the announced text for the result? With something like "Image: This result is potentially sensitive. Click to reveal." or something to that effect? The idea is that this would be the non-visual equivalent of blurring sensitive results.

[rwidom]

I'm so glad to see the accessibility questions here!

Maybe for the alt-text, rather than the title or no on blurred images, we could include the provider and creator names with the standard message about why it is blurred? That's my best guess at some info but not much. I'm not aware of times when the alt-text for an image is not the title. Is that just when a description is available from the provider? Do we know how often that happens?

Also, I wonder a bit about how to fit filter-specific accessibility concerns with existing features and accessibility on the site. For example, this stuff about keyboard focus seems like it could maybe provide another opportunity for differentiating safe/unsafe content, but then I realized that I couldn't (at least with my current Firefox settings) tab-key through the specific search results at all. Similarly, maybe audio transcripts could start with the warning message, if we offered them, but do we? Are they part of our audio provider APIs? I guess I imagine that ultimately we would want the content filters to fit with the overall design, and that that should apply across accessibility features as well. Is there a mechanism for closing those loops?

[sarayourfriend]

I'm not aware of times when the alt-text for an image is not the title. Is that just when a description is available from the provider? Do we know how often that happens?

Right now the alt text for works is always the title: https://github.com/wordpress/openverse/blob/5ca56c9f9270fc02eea7c125942a0d5e33caaa87/frontend/src/components/VSearchResultsGrid/VImageCell.vue#L23

It is also used as the link title: https://github.com/wordpress/openverse/blob/5ca56c9f9270fc02eea7c125942a0d5e33caaa87/frontend/src/components/VSearchResultsGrid/VImageCell.vue#L4

And on the single result: https://github.com/wordpress/openverse/blob/439c8749289ebf118c6b79fcdbcc30dd2fa13ef5/frontend/src/pages/image/_id/index.vue#L12

With something like "Image: This result is potentially sensitive. Click to reveal." or something to that effect?

The difficulties for screen reader users will also be managing the experience. Directing a screen reader user to "click to reveal" is kind of meaningless. "Clicking" is a single type of interaction that mouse users use but screen reader and keyboard users generally have to use different interactions for different types of elements. I'm sure screen reader users are probably used to things like that, but it's almost certainly better to say "Type R to reveal", or some such. And what is being revealed? The image? That might be useful for sighted screen reader users but for people who rely entirely on the screen reader, we should be telling them what will be revealed so that they know what to expect: just like a sighted user knows what will happen if they click "unblur".

I couldn't (at least with my current Firefox settings) tab-key through the specific search results at all.

@rwidom if you're on macOS you probably need to enable keyboard navigation at the OS level: https://www.a11yproject.com/posts/macos-browser-keyboard-navigation/

Similarly, maybe audio transcripts could start with the warning message, if we offered them, but do we? Are they part of our audio provider APIs? I guess I imagine that ultimately we would want the content filters to fit with the overall design, and that that should apply across accessibility features as well. Is there a mechanism for closing those loops?

I think we need to be careful to consider that we need to address the present need: presenting all users, regardless of interaction method, with sufficient information to know that a work has sensitive textual content or was marked sensitive by the provider. I want to make sure that the scope of this isn't blown out of proportion to the solution that's needed, particularly as this project can be iterated on and expanded to include additional resources. For audio results, sighted users do not have additional information about the result than a keyboard user (assuming both are able to hear the audio). Adding text to the existing interaction that can be accessed by both works for audio. For images, we just need to indicate to screen reader users that the image is blurred: they won't have that visual context. If we can give them useful hints (which sighted people have through the blurred image) then we should, but it's also not a necessary problem to solve beforehand. Just the fact that the broad context of the sensitivity of the result, indicated by the blurring of the image, needs to be communicated to screen reader users.

Anyway, I just say that, again, to make sure that we're keeping scope in mind and avoiding going down rabbit holes that would make for good projects on their own, rather than additional requirements to the existing project. We need to make the experiences commiserate with the understanding that neither will actually be the best it could be right now.

[joedolson]

There should be a control surface that a screen reader user will interact with to reveal the image; this would be the appropriate place to have text along the lines of "This [content type] contains sensitive content. Reveal the [content type] information." This would unblur the image, as well as restoring the alt attribute/title/other content fields that have been hidden; all of that information should also be hidden for content that's hidden.

I don't think it's important to disclose the mechanism by which the information is obscured; just 'hidden' or 'obscured.'

I also don't think we need to worry significantly about giving non-sighted users the equivalent information of a blurred image; that's an extremely imprecise point to match, as it can range from "it's totally obvious what this image is" to "I have absolutely no idea".

Using a keyboard command is possible, but will require a lot of testing, as screen readers frequently override keyboard commands. It would be better if there was a control that could receive focus that provided that information and action.

'R', for example, is "Next landmark region" in Jaws 16+.

[sarayourfriend]

Thanks @joedolson. That direction is very helpful, especially the context about keyboard commands.

the equivalent information of a blurred image

Definitely not, I'm not sure if it's even possible with our current resources. I meant that we need to give screen reader users the context that the blurred image communicates (that the result may be sensitive), not that we need to communicate the blurred image somehow via text. A good clarification to make, to be sure.

[rwidom]

@rwidom if you're on macOS you probably need to enable keyboard navigation at the OS level: https://www.a11yproject.com/posts/macos-browser-keyboard-navigation/

Hmmm, I guess that's what was confusing was that I was able to tab around the site, I just wasn't able to use tab to get to the individual results themselves. I'm a total newbie without sensory impairments, so it may be a non-issue for the pros, but on the search results page, when I first hit tab a "Skip to content" button popped up (not a text box or list), and then if I hit tab, it went to the search form and when I kept hitting tab it eventually went to the bottom of the page, but never the results themselves. And if I hit return from the "Skip to content" button, it went to the "Load more results" button at the bottom of the page. But I haven't been able to figure out how to get to the individual images, and I don't see those controls on Big Sur. :/ (These are the results I was playing around with: https://openverse.org/search/?q=orangutan )

[rwidom]

Update to add that I did find a relevant firefox setting ("Always use the cursor keys to navigate within pages") that allowed me to tab to the beginning of the heading for the results (i.e. the word Orangutan), but when I used my keyboard arrows to try to get to the results themselves I got stuck on "See all images" and from there, the right arrow no longer worked, and tab brought me to the bottom of the page again. Sorry if this feels like an irrelevant rabbit hole, happy to make an issue if that would be helpful.

[sarayourfriend]

@rwidom pinged in Slack to move the conversation out of this thread.

[zackkrida]

@panchovm welcome back! I think the only remaining questions here, after the excellent follow-up discussion about accessibility, and refinements to language, are:

1. How do we address audio? In the case of audio, in the search results view the only thing that could be visually sensitive are the audio titles. As an example I experimented with blurring only the titles:

2. From @sarayourfriend:

   the project proposal mentions being able to blur and reblur results from the search results page. I can't tell if the solutions described here include those, but it isn't in the videos shared (unless I missed it). I think this is also something that we can iterate on or cut from the project proposal but that either way we need to do so explicitly.

Once we answer these, perhaps we only need a final revision made to the mockups before this is ready for development.

[fcoveram]

Iteration 3 (i3)

Thanks for all your thoughts. Very fruitful discussion. I’ve been working on a new iteration that you can find below.

Search results

In this version I included the three results pages: All content, Images, and Audio. All these pages have the same interaction as in i2 to surface sensitive content: open the filters to enable/disable the feature in the settings area. Here you can see the default and the sensitive included version per content type. Put attention to the blurred items.

Results page	Default	Sensitive included
All content
Audio
Images

Since this version includes audio content type, texts in the settings area were updated to cover image and text contents. This is open to change, so please leave your thoughts about the copy.

Image results have two very similar component variants. Aspect ratio is the only change, box in All content results and rectangle in Image results. However, audio component has four variants that mix image and text content, cover image for the former, and title and author for the latter. Here is a diagram of the variants with the possible sensitive content blurred.

Plus the above, global player also faces a similar situation.

Unblur/blur individual items

As pointed out in the implementation plan, users should be able to unblur/blur individual results. This requires adding a feature for each component variant listed above.

While exploring a design for the 3D model integration project (#558), I thought about setting content and actionable areas in the box section of each component. This rule would help us to address interaction and content needs and sets the baseline for future designs.

But after testing some ideas, I encountered four reasons to put this feature aside and tackle it in the future:

1. Consistency across breakpoints: Audio component variants are the most challenging as they show up differently per breakpoint and in "all content" results.
2. Interaction in touch devices: Audio and 3D model components have the non-hover state of touch devices solved as they display the action all the time. But adding a third one requires testing and stressing all components to cover all uses cases.
3. Ongoing core interface improvement project: Project #415 is currently updating the button component, and once done, it should address other related and dependent UI elements.
4. New target size (2.5.8) in WCAG 2.2: This new version plans to change the size required for the target area and that impacts the smaller variants of content type components. The guideline is still in draft, but it should be released soon.

These reasons do not diminish the value of the feature, and I see benefits on browsing blurred results and unblurring individual items. But due to the above, I would pause this feature for now.

What do you think?

---

Single result page

For the single result page, users opening a link or clicking on a blurred result, the page remains almost the same. The only changes applied were three:

1. New dynamic descriptive texts below title, as suggested by @sarayourfriend here
2. New style of buttons, based and dependent on #415 project.
3. New show/hide action in the page. It is on the top-left corner now, based on this interaction idea.

Hidden content

Visible content

[sarayourfriend]

These reasons do not diminish the value of the feature, and I see benefits on browsing blurred results and unblurring individual items. But due to the above, I would pause this feature for now.

This sounds good to me. I agree that it is not worth delaying the feature to solve the complexities of what is a "nice to have" rather than a core necessity. This is definitely something we can revisit in the future, probably after user testing and finding out if it is something people even actually want to be able to do.

The solution for audio on the search results page also seems fine to me. My only small question is whether playback should be disabled on the search results page for sensitive audio results.

The single results page also looks great to me. The only note is probably that for keyboard navigation, we'll want to make sure that the reblur/hide button is what is focused when the blur is disabled. Where will the reblur/hide button go for audio single result pages?

New dynamic descriptive texts below title

I don't think we need to sort all of this out now, but in revising the implementation plan for the API side of this project (#996), I realised that we can further disambiguate between content marked sensitive by the provider and content that was reported (and confirmed) as sensitive by users of Openverse. Luckily this won't require adding a new clause/phrase to the copy more complicated because provider supplied and user reported sensitivity are mutually exclusive. We'll just need slightly different wording for each and only ever show one or the other.

[joedolson]

Something I failed to note in the earlier drafts was the use of 'read more' under the Safe Browsing header. That should use meaningful link text built into the context of the sentence; or the heading could be linked.

[fcoveram]

…we can revisit [the feature] in the future, probably after user testing and finding out if it is something people even actually want to be able to do.

+1 to this idea

My only small question is whether playback should be disabled on the search results page for sensitive audio results.

I don't think we should disable it. For image results, landing in the page shows the content immediately, whereas in audio results, text is shown immediately (and that's why it's blurred) but audio requires an action to toggle and listen to it.

In this vein, the flow that feels odd to me is:

1. Landing in audio results, default settings where sensitive content is hidden
2. Open filters and enable showing sensitive content, but keep content blurred
3. (Audio texts and cover image are blurred, but playback is enabled) Playing an audio result
4. Clicking on the blurred text of audio title to go to its single result page
5. Landing on the blurred page of audio's single result.

If a user plays an audio (step 3) and then wants to see the audio details (step 4), landing on a blurred page (step 5) feels clunky as playing the audio by clicking on the play button is a consent action. This thought comes from the idea that from all content in an audio file (title, author, cover image, audio) the audio itself is more important than the others. In other words, a "good" audio is judged by its sound than the file title.

I don't think the flow described is critical and blocks the i3 designs. But I'd like to see your thoughts.

Single result view

…['read more' link] should use meaningful link text built into the context of the sentence; or the heading could be linked.

I thought the opposite was considered a good practice. Thanks for the input.

After showing the page, I tested the "hide content" action inside the audio component, but the interaction becomes complex and doesn't set a long-term approach for future integrations. And since we plan to tackle the modal integration (#429) it makes sense to set the action out of the content area.

Here are the mockups for xl and xs breakpoints. Some mockups were cut off to optimize the comment size.

xl

Page	Mockup
Hidden page
Image
Audio
Audio. Playing

xs

	Hidden page	Image	Audio	Audio. Playing
Mockup

---

Modal (early draft)

Sharing two ideas I was testing for this feature

[fcoveram]

The Mockups page was updated with the last changes. All assets are ready ✨

[sarayourfriend]

Shall we close this issue and continue further discussions when the implementation plan is published?

[fcoveram]

That sounds good to me