Possible misleading use of the checkmark icon on link buttons.

Adding tags

Tagging issue for DrupalCamp NYC ... I think this may be a good example for the contributions workshop.

I am working @eadunn and @rkoller mentoring at DrupalCamp NYC 2020 to take a look at this issue. We think the next step is to take screenshots to document the issue summary and discuss the proposed resolution.

As Matt stated in #4 I am working with @mradcliff and @rkoller at DrupalCamp NYC 2020 to take a look at this issue.

As @mradcliffe stated in #4 I am working along with him and @eadunn on the issue.

We have noticed few inconsistencies in regards of appearance page and its buttons.

The icons are inconsistent on the page. The "Install new theme" is utilising the + button. While if you go to the uninstalled themes section, there a theme card has an "install" button and an "install and set as default" button. both buttons use the checkmark icon. It would be beneficial and more straight forward to use the plus button for all buttons related to the install process. Then the checkmark would make more sense for the "set as default" process.

On the other hand removing icons entirely from the appearance page like suggested might be problematic putting even more cognitive load for sighted users to process the page and the informations. And @eadunn is preparing screenshots to illustrate the comments right now.

I've uploaded screenshots from 9.2x to support the inconsistencies documented in comment #7

I added the screenshots to the issue summary.

Consistency of the icons used on the Appearance page as recommended in @rkoller's comment #7 is supported by WCAG 2.1 Success Criterion 3.2.4 Consistent Identification (Level AA): Components that have the same functionality within a set of Web pages are identified consistently.

The intent of this Success Criterion is to ensure consistent identification of functional components that appear repeatedly within a set of Web pages. A strategy that people who use screen readers use when operating a Web site is to rely heavily on their familiarity with functions that may appear on different Web pages. If identical functions have different labels (or, more generally, a different accessible name) on different Web pages, the site will be considerably more difficult to use. It may also be confusing and increase the cognitive load for people with cognitive limitations. Therefore, consistent labeling will help.

This consistency extends to the text alternatives. If icons or other non-text items have the same functionality, then their text alternatives should be consistent as well.

If there are two components on a web page that both have the same functionality as a component on another page in a set of web pages, then all 3 must be consistent. Hence the two on the same page will be consistent.

While it is desirable and best practice always to be consistent within a single web page, 3.2.4 only addresses consistency within a set of web pages where something is repeated on more than one page in the set.

As for the proposed resolution, removal of the icons used on the Appearance page would likely be problematic by increasing cognitive load for sighted users to process the page and the information as @rkoller stated in comment #7. From an accessibility perspective this would be especially detrimental to sighted individuals with cognitive disabilities, since usually, the best advice to help users with cognitive disabilities is to provide information in multiple formats, with a heavy emphasis on visuals. According to WebAIM's Cognitive Disabilities - Design Considerations, one of the recommendations to accommodate comprehension deficits is by introducing supplemental media such as illustrations, icons, etc.

For more information visit W3C and read more about Additional Support for Cognitive Accessibility currently underway.

Updated the proposed resolution to change the icons to be more consistent, rather than removing them.

Tagging this issue for first time contributors at DrupalCon Prague 2022.

I'm working on this during DrupalCon Prague 2022

I've sent a merge request: https://git.drupalcode.org/project/drupal/-/merge_requests/2789

Took some screenshots. #18 only affects the "Install"-Buttons, where the checkmark is replaced with a plus. The "Install and set as default"-Buttons and the "Set as default"-Buttons are unaffected.

@RobinCS thank you for your feedback. I understood the task (including the discussion) so that everything containing the "set as default" action should remain unaffected. Maybe I understood it wrong.

If we agree that that we want to change the remaining checkmarks too, I will adjust the code.

As I understood it, the checkmark icon has the general meaning of "This Task is done", "This item is applied." and similar. This is not the meaning of the Install, Set as Default or Install and set as Default Buttons. So using a checkmark icon there is misleading.

The Plus-Icon is a good icon for the Install Buttons, as it has the meaning of adding something.
What is missing is a icon for the Set as Default Button. Both, + and ✓ don't seem to fit. I can't find a better alternative though.

For the Set as Default and Install and set as Default links: what about a "house" icon? Something simple, similar to https://www.iconfinder.com/icons/1904661/building_dashboard_default_home...

Or even something like https://www.iconfinder.com/icons/4243280/basic_app_home_ux_icon for Install and set as Default?

thank you for working on the issue! i agree with #20 the scope of this issue was, according to the proposed resolution section in the issue summary, to solely change the icon for the install button. i've also applied the patch and it looks good. not sure if any tests would be necessary for this one since it only changes the $links_item['link'] type from checkmark to plus.

In regards of the icons for the Set as default and Install and set as Default buttons i am leaning towards opening a follow up issue for that. because in particular for Set as default there is no icon with a general consensus communicating "default". therefore making changes to the checkmark within drupal has to be carefully thought out and discussed upfront imho. cuz people are used to the checkmark at least so if changed the new one has to be visually distinct. I am in the same place like @RobinCS on one hand + and ✓ don't communicate set as default well and on the other hand i am also out of ideas what would be a better choice at the moment.

about the suggestion in #22. i am not sure if the house icon would be the best pick for communicating "default". the house is usually used for "home" aka returning to the home page. so not sure if people would associate "default" with the house icon and not getting confused instead.

As there was no further feedback, I started the child issue https://www.drupal.org/project/drupal/issues/3318529 and I think we can leave the #18 commit as it is.

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 200, following Review a patch or merge require as a guide.

Can the MR be updated for 10.1 please.

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 200, following Review a patch or merge require as a guide.

Issue summary appears clear and lines up with the solution in https://git.drupalcode.org/project/drupal/-/merge_requests/3128#note_139129

Applied patch cleanly to 10.1
Verified install is a checkmark but install and set as default is + sign.

Change looks good to me

I am reviewing the RTBC queue. This is making a UI change but I don't see that is has been tagged 'usability' as per the Usability core gate. Perhaps that should be 'needs ux review'. Or has a review happened? Can we either get an ux review or, if that has happened, an issue summary update on the discussion

Also, the issue summary say 'Yes' there are UI changes but doesn't show a reviewer/committer what they are!

Setting needs work to confirm that all the usability requirements are met.

Thanks

We discussed the issue at #3329009: Drupal Usability Meeting 2023-01-06. The direct link to the recording of the meeting is https://www.youtube.com/watch?v=sPDPuRnL0EA

For the record, the attendees at the usability meeting were @ABElliott, @BlackBamboo, @benjifisher, @rkoller, @shaal, and @xjm.

There was a consensus in the group in line with #7, #10 and #11 that using a plus icon for the install action link would make things consistent with the + add button and be an overall improvement. The currently used checkmark icon, which is more of a status indicator, conveys the exact opposite message, appropriate for something that is already installed, rather than an action to install something.
The checkmark icon is still used for the install and set as default and the set as default buttons. The key question if all action link icons should be updated within the current issue or if changing the icons for install and set as default and the set as default buttons could/should be moved to a follow up issue (already created in #25) is :

Does it make it worse if we don’t handle it in the same issue

The consensus was not handling it in the same issue doesn’t make it worse and it would be fine to just change the install icon in Drupal 10.1.

There was also some discussion about the styling of the buttons itself. In Drupal 7 the action links were just text based without any icon and they were clearly styled as links so it is clear that they are clickable. In Drupal 8/9/10 the action links are styled with an icon and small dark grey micro copy. But they aren’t directly distinguishable as links but neither as buttons, the user has to hover over an action link with the cursor. So it isn’t directly necessarily apparent that they are buttons and clickable. Before making any direct recommendations in that regard it was agreed to first research the history and the decisions behind the current design:

Following the meeting I’ve searched the issue queue when the current design for the theme card component was introduced. The first mention was in the following comment: https://www.drupal.org/project/claro/issues/3023319#comment-13229942 The foundational work happened in #3036732: Action link component while the initial work happened on Github: https://github.com/drupalux/claro/issues/8 . @andrewmcpherson clarified and covered the details we’ve talked in this comment: https://github.com/drupalux/claro/issues/8#issuecomment-398850659 so the current state of the action link component is perfectly fine from an accessibility perspective. It might be explored if it would make sense to rethink the button styling to make it more clear that the action links are buttons and clickable. But that is out of the scope of this issue.

Another point in regards of the action links, @xjm mentioned there is an effort in Core not to have more than two buttons in a row - to have fro example one primary action and one associated action like a cancel button if possible. For installed themes you can have at least three action buttons (settings, uninstall, set as default). In that context #3249379: Make all form submissions on the Appearance page consistent was brought up. Currently the appearance page combines immediate actions triggered via the action links with a way to set and save a the configuration what is the active administration theme. One option might be to add drop buttons like suggested in the linked issues issue summary or instead add a second select list for the default theme next to the select list for the administrator theme in the field set at the bottom of the appearance page. But that is out of the scope of this issue as well.

In summary the consensus for the next steps is:

• The scope for this issue should not be expanded.
• The checkmark icon should just be replaced with the plus icon for the install button (which is provided with MR2789).
• This issue should be add as a child issue of #2860419: [Meta] Appearance page is too long and confusing
• Changes about a potential replacement of the checkmark icon for the set as default button should happen in a follow-up issue #3318529: Replace the "Set as default" and "Install and set as Default" icons in Claro theme as well as the discussion and potential exploration if it is necessary to make the design of the action link buttons more clearly button like (without requiring to hover over one).

I've added #2860419: [Meta] Appearance page is too long and confusing as the parent issue, added before and after screenshots for the theme card component to the issue summary as requested in #31 and i've removed the Needs usability review tag.
The only thing i am uncertain is to which issue status i should set the issue? The issue is more or less good to go since most of the potential changes are moved to follow up issues so Needs work seems inappropriate. At the same time Needs review seems also not quite right since the review of the issue happened during the usability meeting with a consensus that there shouldn't be any more changes within this issue. But at the same time i am not sure if it would be right for me to set the issue to RTBC since i've followed it along for a while. So i lean to set it to Needs review instead so someone else could take a final look and set it to RTBC?

Since this issue was RTBC in Comment #30, I think it is appropriate to set the status back to RTBC now. It was set to NW in #31 for a usability review, which was added in #33.

Comment #31 also suggested adding the "Usability" tag. I agree with that, so I am adding it.

I do not see any Novice tasks left, so I am removing that tag.

Adding credits from the usability meeting.

Re: #26, note that the "plain diff" link from the 9.5.x MR does actually apply cleanly to 10.1.x, so (since there are no automated tests for this functionality) a new MR wasn't strictly necessary. However, since @smustgrave specifically asked for one, and since this is a UI change that will only be committed to the development minor, I'm still granting credit for it. Also adding credit to @my-family for the initial MR, to @mradcliffe for mentoring, to @RobinCS and @eadunn for reviews, to @ultimike for the initial issue report, and to @cindytwilliams for the IS update.

I agree with scoping the "set as default" and other items from #33 to followups, since the current scope is still an improvement even if we eventually decide to change the icon for "set as default". (I.e., it's not harmful to UX for the icons to be different, since the links have different meanings.)

I was suprised that there was a whole API for _claro_convert_link_to_action_link(), but since it exists, it makes sense to use it.

Committed to 10.1.x. Thanks!