Improve "Visibility" and "Publish" labels in Post Settings

[afercia]

Example:

The "Public" and "Immediately" controls in this example don't reflect the available action, instead they reflect the current state of the underlying option. I'd say this is a bit confusing also visually. Additionally, when read out of context, users won't have a clue what, for example, "Immediately" relates to.

UI controls should always be meaningful. Looking at the controls in the current WordPress Publish box, the state and the action are separated and the "Edit" controls have an expanded screen-reader-text. Theres a good reason for that. The current design implements what I'd consider without doubts an accessibility regression. Note: this could be implemented also with aria-label.

[jasmussen]

✨ Another great ticket. I will possibly ping you again as this gets implemented.

[joyously]

It's the Pending Review one that makes no sense to me. (I can't ever tell if those "switches" are on or off, even with a color.)

[afercia]

@joyously right, maybe worth a separate issue. Just noting other similar switch toggles have a visible on/off label in other parts of the proposed UI:

[afercia]

A quick comparison of the switch toggles and some label/controls from the current mockups. Apart from small design details to define, should the switch toggles always have a visible on/off state indicator? (for a11y: yes).

Also, ideally form labels should not contain links (I know that WP currently does that, but it could be improved).

Note: the switch toggles would need some a11y special treatment. It's definitely possible to make them accessible, but I guess this should go in a separate issue.

[afercia]

To clarify, ideally the Visibility and Publish button should just identify what they do (the underlying available action): "Edit Visibility" "Edit Publish Date"

The visual presentation of the current settings value should be separated and not be part of the buttons.

[afercia]

To further clarify why this design pattern is far from ideal because control labels containing the setting value or state don't make sense when read out of context:

[afercia]

I'd also like to point out this metabox name is "Status & Visibility" but then when I open it, there's no label or control that refers to a "Status". While this may be implicitly clear for experienced WordPress users, I wonder new users wouldn't have a clue what the "status" references in the metabox name is.

Quick Classic editor / Gutenberg comparison:

[afercia]

About the "Visibility" and "Publish" buttons (which actually are labeled with the value of the options) I'd also recommend to have a look at the testing session by @sinabahram recorded by @joedolson at CSUN 2018, starting form minute 8:00 https://youtu.be/qpzyiL7n__0?t=8m and also published on https://make.wordpress.org/accessibility/2018/03/28/accessibility-of-gutenberg-the-state-of-play/

Why we can't just label the button that is now "Public" as the Visibility button with its value set to "Public"?

"Publish" is weird to me, it seems like an action but it's just text ...

To me, this just confirms the confusion users experience with these buttons. Again, they go against one fundamental web design principle: UI controls should be labeled with the name of the underlying action, not with the current value of the underlying setting.

[sinabahram]

I do think it is possible to do both. Again, I’ve volunteered to hop on some free calls and devise some solutions to problems like this if interested?

[afercia]

@sinabahram thanks so much. Yep we could try to do both, if there's some consensus from the Gutenberg project leads. In the current WordPress editor, these two bits of information are separated and they use some plain text and a button, for example:

text: Visibility: Public button: Edit visibility

Not saying that's ideal, it requires a bit of exploration but hopefully it's a bit clearer.

In Gutenberg I'd suggest to try something like:

button: Edit visibility: Public

and

button: Edit publish date: May 2, 2018 3:53 pm

or something along those lines.

I'd greatly appreciate some help on an important issue you've noticed during your testing session: JAWS doesn't read out the value of the editable fields in the post content. I've created a specific GitHub issue for that but haven't found a solution yet (insert disappointed emoji here): https://github.com/WordPress/gutenberg/issues/6002 Will ping you on that issue, thanks!

[sinabahram]

There are known best practices for this stuff, just not written up very well. it’s why folks like me spend so much time with various devs on calls, in person, etc. … Happy to do a bit of a brain dump whenever the willingness and availability exists. Problems like this one should take a few moments to solve, no more, as there are ways of doing so that don’t affect the visual UI and maintain the accessibility for AT users. For example, that needs to be a single control, and we could obviously have the button serve that purpose, then throw aria-hidden on the current status. the single control needs to advertise current state and what will happen if its toggled e.g. “changes to private” or whatever.

[folletto]

I've done some brainstorming with @afercia to come up with a solution here... we found one that while doesn't reach the ideal state we'd love to have, it should still be a solid improvement on what is happening now:

This approach works by changing the visual slightly, and attaching a <label for="">Visibility <div>Public</div></label> with the for target being the "Change" button. The outcome is that "Visibility: public" is being spoken instead of the button content.

The benefit of this approach are:

1. Works with screen readers, in a way similar to the other controls (with dropdowns) in the same page
2. It adds a much needed label to the value visualized, providing much needed context.
3. It makes the "Change" action explicit for everyone.
4. Bonus: the label is clickable too, making a larger tappable area useful to both desktop and mobile.

The remaining issues this approach wouldn't solve are that basically might be even better if "Change visibility" was spelled out entirely, instead of relying on aria-expanded to hint at the action.

Yet, should be an improvement.

Thoughts?

[jasmussen]

That seems good! Is there space so visibility v public can stand on one line, or wrap if it needs to for translations?

[folletto]

If it was only for "Visibility" it might have been possible. However, I think it would be odd to have "Visibility" on one line, and "Publish" on two (note: in the mockup I changed only "Visibility"). For symmetry, and also to avoid potential issue with text going too long in translations, I think both should go on two lines.

[anevins12]

Sorry long thread and I apologise in advance if I've misread or duplicated someone's response. Looking at this from a conformance point of view, are we trying to reach AA? I understand that we should focus on the user experience and real A11y issues, but the W3C have already gone through a lot of the user testing for us and we should be able to say "because this conflicts with the W3C I don't think it'll be a good experience".

So, if we're aiming for WCAG AA compliance, I'm afraid we're not describing the action of buttons or links when using the date (for example) as the textual description.

https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G131

[bemdesign-er]

Labels should clearly articulate what the control does so users can understand what the expectations are for using that control and possible results of their actions by using that control. This is good for both usability and accessibility. Also consider the use case of a screen-reader - does the label clearly tell the user what the control is and what it does?

[folletto]

The latest proposal above (https://github.com/WordPress/gutenberg/issues/470#issuecomment-387169279) will speak:

Visibility: Public, collapsed, button

So it both describes the button ("Visibility" → "Identify the purpose of the interface component.") and the content ("Public"), as well as the state ("collapsed") and the type ("button" → "Check that each label makes the component's purpose clear.").

Any reason why you think it doesn't match the requirement?

[afercia]

Any reason why you think it doesn't match the requirement?

Yes: there's no consensus and no progress yet 😄

[afercia]

Looking again into this, it's a bit more complicated than how it seems for at least two reasons:

• it's not just about Visibility, it's also about "Publish" and having two "Change" button would be confusing for all user and hard to use for speech recognition software users
• when users have no permission to edit, there's no button rendered; there's only a text with the Visibility state, so also the label should be rendered conditionally...

[tofumatt]

@mtias wanted me to check if this is still an issue and what's actionable here.

The issue is still valid because the label for the current state is also a button that opens the visibility settings (for "Public") and a date picker (for "Immediately").

I think the most accessible version of this (and possibly the easiest to implement) is doing what the old WP-Admin did: having the current status and an "edit"/"change" button next to the status to change it.

Alternatively we could label the current links to have an off-screen, for screenreaders, bit of text that contextualised things. The text could be, for the datepicker: <span class="screen-reader>Date to publish:</span> $DATE <span class="screen-reader>(Click to change)</span>

That could work but I think it's a bit more awkward for users and to code. I think putting the change buttons next to the current state would be best, visually using what @folletto mocked up.

[afercia]

We should consider not only screen readers. Ideally, a label should be visible and communicate the action. For example, speech recognition software users need to know the accessible name of a control to voice a command. The accessible name should match the visible label or at least start with it. See https://www.w3.org/TR/WCAG21/#label-in-name

[tofumatt]

Yes, that's why my first suggestion was to replicate the classic editor implementation; the button to edit is visible, contains text that says what it does, and is distinct from the status:

Visibility: Public (<button>Change <span class="screen-reader">visibility</span></button>)

That would work, right?

[GlennMartin1]

Hope it's not out of place to mention this here:

See https://github.com/WordPress/gutenberg/issues/6604 about a mobile issue of not able to change Visibility settings on mobile.

(the related issue of changing dates on mobile is resolved).

[afercia]

That would work, right?

Yes for screen reader users, no for sighted users with accessibility need. For example with 2 "Change" buttons that look the same, what command speech recognition software user should voice? The command "Click Change" wouldn't help to directly activate the buttons. Also, users with visual impairments of cognitive impairments would be potentially confused by two buttons that say the same thing. The best option would be using a visible, meaningful buttons text:

<button>Change visibility</button>
<button>Change date</button>

Or "Edit" instead of "Change". I do realize the space is limited, but that's a design issue. Design should adapt around content, not vice-versa.

[afercia]

Also, it's not the only case of UI controls labelled with the underlying state instead of their action 🙂

[tofumatt]

Indeed, but I'm just trying to start someplace 😄 I think these are the only ones in the document sidebar. 😅

I am for the full text visually from an accessibility standpoint, but there's barely space for it in English and I worry about translations. Maybe with @folletto's mockup we could try that. I'd be for seeing someone give it a go, so we'd have:

but "Change" would be "Change Visibility" (or edit, or whatever we pick 😄). That'd work for me for accessibility and design unless I'm missing something.

Bonus: maybe we could make it a real button instead of a link-button, because I find them confusing… I was happy when "Move to Trash" recently became a button 😄

[afercia]

Ah yes ideally buttons should look like buttons 🙂this is a long standing issue also in core where there's some uncertainty about what a UI control is: link? button? will it work with spacebar? We'll see.

Worth reminding visibility and publish are also available in the publish panel, same issue there:

[folletto]

Visibility: Public (<button>Change <span class="screen-reader">visibility</span></button>)

Just to make sure it's not missed: the mockup above also specifies semantic markup that uses the for label to associate the label on the right to the button itself, which is used by assistive tools to mark the button properly — i.e. it's used as speech which differentiates the two buttons even if they have the same label.

[davewhitley]

Here is a proposal for a possible compromise or alternative solution. A couple of concerns I attempted to address:

• The click target is much too small, and requires high dexterity to click the small link (applies to both Classic and Gutenberg editors).
• The font size is small and hard to read.
• As mentioned several times above, the linked text does not describe the action.

Some notes on the design:

• The icons used are just examples, we can switch them out for different icons.
• The whole row is clickable, providing a large click area.
• Similar to how the X icon means "close" and the cog icon means "settings", the pencil icon is widely understood to mean "edit".

I admit that I'm not well-verse in the intricacies of speech recognition software, so any guidance on that would be appreciated.

If this is a viable solution, I'd like your feedback on it!

Update: I removed the left decorative icons because they were unnecessary.

[anevins12]

The whole row is clickable, providing a large click area.

I think that would be unpredictable to people using speech assistive technologies. What do they say in order to edit the publish date, do they say "Publish date", or "Publish date october 9, 2018 7:27", or do they say "Publish date edit". I recommend keeping labelling for the interaction succinct and predictable.

[tofumatt]

We can use aria-label and keep the clickable area large; the increased click area improves accessibility for mouse users, especially those for whom small, precise click targets are an issue.

I love @drw158's design here. For screen readers I'd imagine we'd want to use an aria-label that read something like "Publish Date (click to edit)" or something like that? Could we use aria-describedBy for the date itself? 🤷‍♂️

[sinabahram]

Please note that aria-label will affect the accessible name of the component in question; therefor, it should be tested that speech recognition software still triggers the given component based off of the visible lable.

also, I suggest not using modalities in labels, but definitely not click at any rate, since the very audience the label is targeted for can’t use said input modality for the most part 😊

there used to be an issue whereby aria-label, but not aria-describedby, would make it into the Braille Display representation of a component, so you may wish to chain together an aria-label and aria-labelledby so as to affect the accessible name but not the accessible description of the component for purposes of Braille users.

Hope that helps.

[afercia]

Thanks @sinabahram. I'd add that UI controls that use only icons like the proposed "edit" buttons above don't really help. As mentioned in the previous comments and in various other issues in this project, controls that use only icons should be avoided at all costs. (speech input users, low vision, cognitive impairments, etc.)

[alexislloyd]

I think @afercia's original point here is a good one:

The "Public" and "Immediately" controls in this example don't reflect the available action, instead they reflect the current state of the underlying option. I'd say this is a bit confusing also visually.

I think @drw158's design does a very good job of addressing this, and also creates a larger, more usable click area in the process. This, in addition to @tofumatt's point about using aria labels for clear non-visual controls, seems to be a good solution.

As a secondary note, in re:

controls that use only icons should be avoided at all costs.

My understanding from accessibility guidelines is that the requirement for non-text content is to make sure there are text alternatives — alt text, aria labels, tooltips, etc. While visible text labels on controls are desirable in some cases, if every control has a visible text label, then we create a lot of clutter and put other accessibility requirements at risk, in terms of creating cognitive overload for users.

[joyously]

if every control has a visible text label, then we create a lot of clutter and put other accessibility requirements at risk, in terms of creating cognitive overload for users.

I can understand this sentiment, but I think it does not take into account the cognitive overload for those of us that can't decipher icons. We either can't see them well, or have no idea what they mean. I read English, not hieroglyphics.

[alexislloyd]

I can understand this sentiment, but I think it does not take into account the cognitive overload for those of us that can't decipher icons. We either can't see them well, or have no idea what they mean. I read English, not hieroglyphics.

I think this is where tooltips and alt text come into play, to provide additional context if an icon isn't apparent. This is where it's a balancing act of finding a balance of usability for everyone, understanding that increasing accessibility for one user may decrease accessibility for another. This isn't to discount any one experience, just to acknowledge that there's no perfect answer.

[afercia]

My understanding from accessibility guidelines is that the requirement for non-text content is to make sure there are text alternatives — alt text, aria labels, tooltips, etc. While visible text labels on controls are desirable in some cases, if every control has a visible text label, then we create a lot of clutter and put other accessibility requirements at risk, in terms of creating cognitive overload for users.

@alexislloyd thanks for your feedback. Totally agree it's a balancing act. However, I don't think a short visible text like "Edit visibility" adds more cognitive load than what an icon does. I'd say icons are way more problematic.

From an usability perspective, I could cite a well known study about Icons Usability from the Nielsen Norman Group, and there's plenty of research about the cognitive load added by icons, cultural differences, lack of universal meaning, cognitive impairments, etc.

More generally, I'd like to invite everyone to consider that "icon-only" UI controls are part of what I'd call an "appification" design trend which, in my opinion, doesn't really fit with the true nature of the Web. Mobile apps live in a controlled environment where even the hardware is known. Pattern and paradigms used on mobile apps aren't necessarily good for web applications.

Instead, the Web is designed in an "agnostic" way, is designed to work for everyone whatever their hardware, software, language, location, or ability. In this sense, icon-only controls are an anti-pattern. Of course, for what is worth, this is just my personal opinion.

I can understand the "clutter" argumentation but I'd easily argue that an user interface should be designed around its content, not the other way around. If there's not enough space, then I wonder why this part of the UI has been designed this way in the first place.

Re: text alternatives. Correct, but when it comes to UI controls things are a bit different. The name of an UI control needs to be perceived by all users. As accessibility team we've asked to have at least tooltips to expose the controls name. However, that's a trade-off. Not all users are able to use a mouse to hover a control and reveal its tooltip or use a keyboard for the same purpose.

Consider speech input users: they need to see a control name to be able to voice a command. They can work around this issue but that requires tabbing multiple (sometimes dozens) of times to get to a control to make its tooltip appear. I'd like to invite @ewaccess to explain better what are the needs of speech input users and why visible control names are always preferable. Eric when you have a chance, that would be greatly appreciated thanks 🙂

Worth noting the accessibility team published a few user testing sessions. In one of them (shared in a make blog post and also with the Gutenberg team on Slack) @ewaccess was so kind to run a 1 hour testing session on Gutenberg. See https://make.wordpress.org/accessibility/2018/03/28/accessibility-of-gutenberg-the-state-of-play/ I'd recommend everyone to watch that video to get an idea what a person has to do when UI controls don't expose their name visually. The session is from March 2018, many things in Gutenberg have changed, but the icons issue is still there.

I'd also invite to take into consideration a recent user testing session that was shared on Slack in the #design channel. One of the tasks asked to change the image in an Image block. Users took from about 1 minute and a half to 4 minutes (4 minutes!) to understand what they had to do. Most of them totally ignored the "pencil" icon. And they were users with no specific accessibility needs. Admittedly, a block toolbar has many icons and I guess that contributed to the confusion.

Comparing the Classic Editor with the proposed design: these controls in the Classic Editor are far from perfect but at least there's some visible text. In the proposed design, the controls are just icons:

In the proposed design I really appreciate the setting state is separated from the setting name but I'm wondering why to use icons in the first place when there's no actual need for them? I'm not a designer so what you see in the screenshot below is something I've just edited in my browser and can certainly be refined 🙂

Why can't we add the word "Edit" so that the controls names match the controls actions? Added bonus: this way, the clickable area would be larger.

Note: ideally, in the rendered markup, the actual values (e.g. "Public" and the date) should not be within the button element.

[ewaccess]

Consider speech input users: they need to see a control name to be able to voice a command. They can work around this issue but that requires tabbing multiple (sometimes dozens) of times to get to a control to make its tooltip appear. I'd like to invite @ewaccess to explain better what are the needs of speech input users and why visible control names are always preferable. Eric when you have a chance, that would be greatly appreciated thanks 🙂

Thanks @afercia!

Speech recognition users "say what we see." The only viable options for desktop speech recognition are Dragon NaturallySpeaking and Windows Speech Recognition (WSR). Both of these work by having the user say the word "click" followed by "[name of the thing they want to interact with."

Consider the microphone icon in the search box on Google.com. What do I say to activate it? "Click microphone?" It turns out that the label for this control is "Search by voice," so that's what I would say. I learned that by reading the tooltip on mouseover, but many speech recognition users cannot use pointing devices at all.

Consider the icons on the Github editor. Some are easy. "Click bold" and "Click italic" are rather obvious. But the "aA" icon? Without mousing over and finding that tooltip, I would have no idea that I need to speak "click Heading" to activate it. Personally, nothing about that icon conveys "heading" to me. The icon is doubly confusing because Microsoft Word uses a very similar icon on the Office Ribbon to mean "Change Case.' That would've been my first guess at what that control did.

By using icons instead of text labels, users need to:

1. Discover the label
2. Remember what they've discovered and apply it to a particular context
3. Discover if what they can say say actually works. For instance, Dragon users can interact with controls labeled using aria-label, but not aria-labelledby. That's a quirk in the user agent that developers needn't really be concerned about, but at least by using text labels you've left the user with one variable to contend with instead of three.

[joyously]

What if there were some setting that switched the interface from text to icons? Then people could figure everything out, and use the icons if they prefer.

[alexislloyd]

So, a couple of points:

• First, when discussing the icon, we need to be mindful of all of the substantial context around it that clearly indicates what affordance is available. This is present in a settings panel, adjacent to a setting name. It is a fundamental understanding of software that you can click on settings to edit them. The icon is helpful as an additional signal that this setting is clickable, but I think the extensive contextual information is more than sufficient to clearly communicate to anyone who is sighted. As already discussed, for those with visual disabilities, there is explicit supporting information to replace that visual context.

• Second, as we make decisions like this, it's useful to not just think about a one-off solution, but a solution that can be extensible and form the basis of a repeatable pattern for similar interactions. The more we can create that consistency, the more usable the overall product will be, as users won't have to relearn new patterns for every task.

So with that in mind, here is a rundown of several solutions that could be considered and how they stack up in terms of both clarity and extensibility. I laid this out in an image, but am also providing a text version below for anyone who can't see the image.

Option 1

Image description: Each setting heading is the title of the setting (Visibility, Publish date), and the line below is the current status of the setting in smaller text. There is an edit icon to the right.

Clarity and hierarchy: Easy to scan, hierarchy is clearly delineated Each visual area represents a different aspect of the information:

• Header text on the left describes the setting
• Smaller text beneath shows the setting state
• Icon on right indicates the setting control mechanism.

Pattern extensibility: Highly extensible pattern. We could easily have a document or block sidebar with many fields like this, as the pattern of setting description, setting state, and setting control is not one likely to break (and setting state could be removed in cases where not needed).

Option 2

Image description: The setting headers read "edit visibility" or "edit publish date". The line below is the current state in smaller text. The right side has an edit icon.

Clarity and hierarchy: Hierarchy is confusing, difficult to scan The header text on the left is redundant with the icon on the right but is presented as a header for the current state below, even though it doesn’t describe that state.

Pattern extensibility: Not very extensible. “Edit” may not work semantically with all setting names, this field could become very long in translation to non-English languages.

Option 3

Image description: Each setting header text is the current status of that setting. The line below reads "edit visibility" or "edit publish date" in smaller text. The right side has an edit icon.

Clarity and hierarchy: Hierarchy is slightly better but still has the issue of the control text and the control icon being in different visual spaces / not clearly connected.

Pattern extensibility: Not very extensible in that the pattern relies on the setting having a current state to serve as the header, which it may not (or that current state may not be something expressed in words, like a color or an image).

Option 4

Image description: Individual settings are represented by select / dropdown menus with a header (Status or Visibility) and the current status.

Clarity and hierarchy: Hierarchy is clearly defined, relatively easy to scan, though the addition of the outline around the select control adds clutter that reduces scannability.

Pattern extensibility: Somewhat extensible , but may run into problems if the current state is something visual (an image, color, etc.)

Option 5

Image description: Individual settings don't have headers, and are represented by select/dropdown menus that display the current status of the setting.

Clarity and hierarchy: Easy to scan but provides less detailed contextual information about what each field is showing.

Pattern extensibility: Not very extensible in that the pattern relies on the setting having a current state to serve as the header, which it may not (or that current state may not be something expressed in words, like a color or an image).

In short, we're trying to collectively solve the initial issue that was raised here, and to do so in a way that not only solves it in this instance but provides a consistent pattern to follow. Consistency is something that needs to be improved in Gutenberg and is a huge consideration for accessibility and usability across the board, which is why I'm focused on coming up with a solution that isn't just a one-off for this instance but can be applied consistently in instances like this as well. I think option 1 addresses the initial issue and increases accessibility and usability with a larger font, larger click area, clearer information layout, and the intent to have all of that supported by the appropriate alt and aria labels for screen reader / voice concerns. I propose that option 1 represents the best balance of usability, accessibility, clarity, and extensibility and is the best choice to move forward with.

[afercia]

@alexislloyd thanks for your feedback and for the effort. I personally kindly disagree, but I'll wait to discuss this issue with the accessibility team and come to a reply as a team.

I appreciate all the considerations about hierarchy and consistency. I'm a fan of consistency and typography so I look forward to seeing more and more of them in WordPress.

That said, I see what prevails is a visual approach. If we want to succeed in making this project deliver the best balance between accessibility and visuals, we need to learn together to not think visually as a first step. Semantics and meaningful information come first. Seems to me there's not enough consideration for what an UI control should communicate to all users and to software used by users.

For example, Option 1 wouldn't solve the issue for speech input users.

Option 2: the icon is redundant and should be removed. I don't see any reason for an icon when the button text already communicates the available action, e.g.: "Edit visibility". From an accessibility perspective, I think this would be the best option.

Option 3, 4, and 5 are interesting explorations but I think we agree they're less than ideal 🙂

[joedolson]

Is there any crucial need to remove the icon? I'm not sure I can see the accessibility need for removing that icon, as long as it's only supplemental and doesn't carry additional text that would influence the accessible name of the control. For cognitive impairments or people less comfortable with the language, supplemental icons can help identify the purpose of a control more quickly.

[afercia]

@joedolson in the proposed design, text is only text. The actionable control is the icon.

[joedolson]

Ah, well yeah - that's a problem. The text should be the control.

[sinabahram]

+1: I agree. The text should be the control.

[youknowriad]

From what I understood from the design, the actionable control is not the icon only, it's everything. I think this needs implementing to see if it can be made accessible or not, we can't judge by just looking at mockups.

[afercia]

From what I understood from the design, the actionable control is not the icon only, it's everything

Then this should be clarified. If the actionable control is a <button> with a text that clearly communicates the available action, e.g.:

• edit visibility
• edit publish date and the icon is purely decorative, then I guess there are no accessibility concerns. The text representing the state must not be included within the button tough. It should be referenced by an aria-describedby attribute. We'd need to explore some CSS technique to keep it outside of the button, while keeping the whole box as the clickable area.

[anevins12]

You can also use JS to apply the behaviour of the button to the parent element, while still retaining the focus order of the button. So that you can tab to the button and interact with it normally, but as mouse r touch users you can click on the whole area

[joyously]

I was a little confused just looking at the mockups, when there is an icon and text. It's as if there are too many choices (clutter), but I didn't know if I should click the icon or the text that looks like a link. Is accessibility only about impairments? Or am I impaired, since I find it difficult to navigate with all the unknown icons in the way?

[tofumatt]

Because this is still somewhat in discussion, but also because it needs implementation and is a big (UI) change, I'm moving this out of the 5.0 release milestone. I've moved it to follow-up for now.