WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 weeks ago

#28599 new defect (bug)

Better Visual Focus Indication in Admin Menu

Reported by: AccessibleJoe Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.8
Component: Administration Keywords: ui-feedback has-patch needs-screenshots
Focuses: ui, accessibility Cc:

Description (last modified by rianrietveld)

Breaking this issue away from #28267 "Unify focus styles across the admin." The left navigation menu system now uses color changes to indicate visual focus. In the default scheme, when the main menu item is selected the background goes from dark gray to black and when a submenu item is selected the text goes dark blue, both hard to discern. Color alone cannot be the only indicator. For those who cannot perceive color changes, a secondary marker is required. For instance, in the situation where a blue glow is used to show focus on an input, there is the color and the shading in the glow: two elements. The solution should work in the eight available admin color schemes.

Some suggestions have been made including:

  • Helen reports that a blue glow does not look good
  • White outline around menu item with white outline also around selected submenu item
  • Reversing the colors coupled with another undefined indicator element
  • Triangle to the left of main menu item and selected submenu item
  • Underline under main menu item and selected submenu item (might be mistaken for links)

Tracking label: #a11y-color

Attachments (10)

28599-focus-highlighting.diff (1.2 MB) - added by florianziegler 3 years ago.
Use with standard WordPress install
28599-focus-highlighting-dev.diff (2.5 KB) - added by florianziegler 3 years ago.
Use with develop.git.wordpress.org
28599-focus-highlighting-default-color-scheme.diff (3.6 KB) - added by florianziegler 3 years ago.
Changes only the default color scheme
28599-focus-highlighting.2.diff (864.7 KB) - added by florianziegler 3 years ago.
Changes only the default color scheme
focus admin menu.patch (7.0 KB) - added by afercia 3 years ago.
focus admin menu arrow alt.patch (7.3 KB) - added by afercia 3 years ago.
focus admin menu arestad alt.patch (7.0 KB) - added by afercia 3 years ago.
partially explores Michael Arestad idea, no padding/shifting and color changes for now, just to have an idea
28599-admin-menu-focus-bar.diff (2.7 KB) - added by florianziegler 3 years ago.
admin menu focus bar
28599-currentcolor-arrow.diff (4.1 KB) - added by florianziegler 3 years ago.
Using currentColor for the focus bar, submenu indicating arrows now show up on focus
28599-focusbar-border.patch (8.1 KB) - added by florianziegler 3 years ago.
Add an additional border on the left side to get some separation between the admin menu and the focus bar

Change History (107)

#1 @esmi
3 years ago

I'm a really big fan of reversing background and foreground colors, so in the dark default admin scheme, I'd want to see something like a blue background with black/dark grey text for th currently focused element. It's got to really "pop" for sighted keyboard navigators. triangle indicators are very nice as added features for onhover but I'd argue that they're too subtle for focus highlighting. Ditto for underlines. General rule of thumb: if you have to visually hunt for the currently focused element, then you need something else. Get it right and keyboard navigation becomes so much easier.

This ticket was mentioned in IRC in #wordpress-ui by accessiblejoe. View the logs.


3 years ago

This ticket was mentioned in IRC in #wordpress-dev by celloexpressions. View the logs.


3 years ago

#4 @celloexpressions
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version changed from trunk to 3.8

Setting version to 3.8, although this was probably also an issue before mp6/3.8.

I like the color-inversion approach better than adding a border, as it looks more intentional for non-keyboard users.

#5 @celloexpressions
3 years ago

  • Summary changed from Visual Focus Indication in Left Navigation to Better Visual Focus Indication in Admin Menu

This ticket was mentioned in Slack in #accessibility by accessiblejoe. View the logs.


3 years ago

@florianziegler
3 years ago

Use with standard WordPress install

@florianziegler
3 years ago

Use with develop.git.wordpress.org

#7 @florianziegler
3 years ago

  • Keywords has-patch reporter-feedback dev-feedback needs-testing added; needs-patch removed

I made a quick patch, but it still needs lots of work

What it does

:focus now mimics the :hover behavior of the non-default color schemes: The background color becomes the highlight color, icon and text are white. I adapted the same behavior for the submenu links.

In the submenu this works in most cases, but we may need to define another color variable for text of focused links in submenu, because in some color schemes white doesn't work so well. Also in several color schemes some colors are not defined, and the default doesn't work well either. (You will see what I mean, when you test the color schemes.)

The Arrow

The arrow looks really bad (especially in the non-default color schemes), when the focus is on the element of the submenu that is next to the parent. (I guess that's why they did the highlighting in the way it is implemented now.)

https://cldup.com/caGCEUupTE.png

Feedback, please. :)

This ticket was mentioned in Slack in #accessibility by florianziegler. View the logs.


3 years ago

@florianziegler
3 years ago

Changes only the default color scheme

#9 @florianziegler
3 years ago

I was working on src and so all kinds of stuff ended up in the oldest patch. Best to ignore it. :)

I created a new one, that only changes the focus highlighting behavior for the default color scheme.

Right now it still breaks the focus highlighting for some of the other color schemes, but you should get the idea of what I was trying to do here.

@florianziegler
3 years ago

Changes only the default color scheme

#10 @rianrietveld
3 years ago

@florianziegler, thanks for the patch.
I think it's a big improvement. Agree on only fixing this for the default theme.
I still miss the colour change on the collapse menu.
Wondering if we should also change this for the hover state, because its' so much better now on focus and we could make that uniform.

#11 follow-up: @afercia
3 years ago

hi @florianziegler, your latest patch is 864 KB, it includes also .rtl and .min files, that's really not necessary.
Please read the WordPress Core Handbook Working With Patches
You should install the latest WordPress development version via Subversion (SVN) and then you should create your patches from the root directory of your WordPress SVN install.

Please allow me to remember the point of this ticket is about to provide additional visual cues on focus for links or controls where color alone is used to identify them.

Quoting @AccessibleJoe

Color alone cannot be the only indicator. For those who cannot perceive color changes, a secondary marker is required.

So we need a marker, or "shape", or something (outline, border, arrow, whatever...) to clearly indicate focus besides color changes. Preserving aesthetics too, and that's the difficult part :)

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#13 in reply to: ↑ 11 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#14 @florianziegler
3 years ago

Alright. I think, I was way to quick with my "patch". :)

I did a bit of catching up on what was discussed in the past and it seems like it just went nowhere. Ticket #28267 was closed without a solution for the admin menu, even though some suggestions were made around here: https://core.trac.wordpress.org/ticket/28267#comment:18

Will a border (not talking about the technical details yet) proposed here, solve this issue?


This ticket was mentioned in Slack in #accessibility by michael. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by ginsterbusch. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by ginsterbusch. View the logs.


3 years ago

#18 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#19 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#20 @afercia
3 years ago

  • Keywords ui-feedback added; reporter-feedback needs-testing removed

Hi everyone, followed meetings and discussion on Slack and this ticket, I'm currently working on an alternate patch.
Before going ahead though, I'd like to involve everyone in the discussion, including lead devs and contributors and listen to any thoughts and feedback.
It makes no sense to spend a lot of time on the patch without a wide consensus :) especially because we're going to propose to (slightly) change the default blue color scheme.

So, the screenshots below are not mockups: they're screenshots of a working patch, that means what you see it's doable and already working but not ready to be attached here for now.

Following the border idea proposed in the Make Accessible blog by @accessiblejoe and others, it would be nice to have the border just on focus, not on hover (technically, it's not a CSS border but it's a box-shadow so it's not supported by IE 8). That's because I would try to respect the current design as much as possible and at the same time have a better level of accessibility.

For now, I would recommend to focus on the general idea, not the technical details. Hope the screenshots are clear enough, let me know.

Focus: 1 - 2 - 3 before the patch, 4 - 5 - 6 after the patch
Please notice the icon and the arrow, now they work consistently on focus too.

https://cldup.com/fWFYJ2RfkV.png

Hover: 1 - 2 - 3 before the patch, 4 - 5 - 6 after the patch

https://cldup.com/FFVaUnOd7d.png

Things to consider:

  1. focus arrow alternate version (maybe nicer?)
  2. focus on fly-out sub item when it's near the arrow (ugly?)
  3. focus on the current parent (looks ok to me)

https://cldup.com/B3q2OYR3r2.png

#21 @rianrietveld
3 years ago

@afercia +1
I think this solves it all.
About the things to consider: maybe someone who knows design can take a look at that.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#23 @afercia
3 years ago

Uploading the patch I'm working on so the Accessibility Team can test it in their testing session. Please notice it's not ready for production and for now it works just with the default color scheme.

#24 follow-up: @helen
3 years ago

  • Keywords has-patch dev-feedback ui-feedback removed

My initial comment that the "blue glow" wasn't a good look also applies to this white border, which is exactly the same thing, just white. I am a no on this approach. Also actively seeking further design feedback.

#25 in reply to: ↑ 24 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#26 follow-up: @Michael Arestad
3 years ago

We could try something with just a left border and maybe a background/color color change. Here's a super quick mockup:

https://cldup.com/2SA3w-G0x1.png

With a transition, it would add a little motion, a contrast from other hover/active states, and work pretty well throughout the side nav. For the top nav, I would go with a bottom border (via box-shadow to avoid repaint) instead.

#27 in reply to: ↑ 26 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#28 follow-up: @afercia
3 years ago

I would propose to be open to explore other options, there's no hurry and we need feedback from all the accessibility team members. It would be great to involve in the discussion as many lead developers and contributors as possible, when they have a chance.

Different ideas were discussed on Slack during the accessibility meeting session.
I agree with @helen that design-wise, what @michaelarestad proposed is better than an outline. Besides accessibility considerations, I see a couple of potential issues with the border on the left, see screenshot below, it's just a quick in-browser editing, please don't focus on colors:

  • the menu has at least 3 views: desktop, folded/auto-folded and mobile; when folded, is there enough space to shift the icon on the right?
  • shifting the item text on the right could break the text in 2 lines just when focused; we can't predict the item text length and having a line of text that breaks in 2 lines when focused looks pretty bad

Thoughts?

https://cldup.com/2Dj6Em-Tm5.png

@afercia
3 years ago

partially explores Michael Arestad idea, no padding/shifting and color changes for now, just to have an idea

#29 in reply to: ↑ 28 ; follow-up: @usability.idealist
3 years ago

.

Last edited 3 years ago by usability.idealist (previous) (diff)

#30 in reply to: ↑ 29 ; follow-up: @afercia
3 years ago

Replying to usability.idealist:

Replying to afercia:
The line-break already happens as soon as you use non-english languages. Last week I wrote a plugin as part of a job and added i18n - I always use English for i18n reasons, no matter that it aint my native language - and as soon as the German translation was in, several menu items broke into two lines.

The point is, using padding just on focus, a long text will be in one line when not focused and will break in two lines when focused.

#31 in reply to: ↑ 30 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#32 follow-ups: @Michael Arestad
3 years ago

Quick note, we can add visual borders without influencing the box parameters (padding, margin, border). Using pseudo elements, box-shadows, or other techniques we can avoid forcing a line-break.

#33 in reply to: ↑ 32 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#34 follow-up: @florianziegler
3 years ago

I like the "left border" on focus approach (however it will be achieved technically). We would have to experiment with different colors and make sure contrast is sufficient. It definitely looks better than the white border!

Question is: Would this solution be enough to count as an "additional visual cue" in respect to WCAG criteria?

IMHO the behavior of hover and focus should be identical. This makes for a more streamline experience.

#35 in reply to: ↑ 34 ; follow-up: @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#36 in reply to: ↑ 35 ; follow-up: @helen
3 years ago

Replying to usability.idealist:

But you know, some folks might find it not "visually appealing" (aka artsy) enuff :-/

This is my kind request we not make derogatory comments about other disciplines or people, no matter how covert. I think we are a strong and well-developed enough project to be able to balance visual design and usability for the majority with affordances for sizable minorities. There is no need to put down one or the other, and we should not and will not tolerate it.

#37 in reply to: ↑ 36 @usability.idealist
3 years ago

-

Last edited 3 years ago by usability.idealist (previous) (diff)

#38 in reply to: ↑ 32 ; follow-up: @afercia
3 years ago

Replying to Michael Arestad:

Quick note, we can add visual borders without influencing the box parameters (padding, margin, border). Using pseudo elements, box-shadows, or other techniques we can avoid forcing a line-break.

That's what the patches are actually doing. Since the beginning I tried to avoid touching the box model, so the only solid options were outline or box-shadow. Nice idea considering CSS generated content too. In the future, maybe, CSS filters.

#39 in reply to: ↑ 38 @florianziegler
3 years ago

Replying to afercia:

Nice idea considering CSS generated content too. In the future, maybe, CSS filters.

Yep!

BTW: The arrows are already "CSS generated", so I don't see why we couldn't harness that to display :focus and/or :hover as well. Browser support is there as well.

(The ::after pseudo element is already taken by the arrow, though, so ::before would be the choice here.)

#40 @rianrietveld
3 years ago

I agree with @florianziegler that this is a beautiful solution. According to WCAG rules the focus should be visible. If the contract ratio between background-left border line and background-text is 1:4.5 or more, I think this is a good solution.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#42 @michaelbeil
3 years ago

i like @michael-arestad's design mockup followed up by what @afercia designed with a "left border" approach most and think it correlates best with WCAG.

#43 @florianziegler
3 years ago

To quickly recap what was discussed in slack earlier today:

  • The bar was declared a sufficient, additional visual cue.
  • Contrast has been addressed separately in ticket #30323

#44 @florianziegler
3 years ago

After last Wednesday's discussion, I (gave it another try and) created a patch. Use "grunt patch" to apply it.

With the patch applied, you should now see the "focus bar" on hover & focus on the left hand side of the respective menu item.

Screenshot:

https://cldup.com/IfT3U7SFmu.png

Behavior of hover & focus is identical.

I also added a transition (like Michael Arestad suggested).

At this point it only works with the default color scheme: I had to include the color scheme's body class ("admin-color-fresh") as a selector in order not to affect the other color schemes. Once the other schemes are adjusted, we can get rid of the body class selectors.

While working on this, I realized that the body class is not updated on the fly, when using the color picker on your profile page, thus causing problems when switching to any other than the default color scheme. I added that (missing) functionality to user-profile.js. (Let me know if this should have its own ticket.)

Please test away and tell me, what you think. :)

@florianziegler
3 years ago

admin menu focus bar

#45 follow-up: @azaozz
3 years ago

Wondering if currentColor can be used here instead of tweaking all color schemes. Ref: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#currentColor_keyword

#46 in reply to: ↑ 45 ; follow-up: @afercia
3 years ago

Replying to azaozz:

Wondering if currentColor can be used here

Hello @azaozz, it would be great if we could use currentColor though I guess IE 8 is still officially supported, any update on this?

@florianziegler hi, it would be great if you could also take care of the fly-out "triangle", it should work also on focus. See my previous patch.

#47 @florianziegler
3 years ago

New patch.

Amazing idea by @azaozz, using "currentColor"!

It now works out of the box for all color schemes! But we need to check if IE8 is an issue/needs to be supported as @aferica mentioned. Anyone?

@aferca: Thanks for the input on the triangles/arrows: They now show up on focus. For them we still need the body class selectors, as to not interfere with the non-default color schemes. Can't use currentColor here, unfortunately. :)

@florianziegler
3 years ago

Using currentColor for the focus bar, submenu indicating arrows now show up on focus

#48 in reply to: ↑ 46 ; follow-up: @azaozz
3 years ago

Replying to afercia:

...I guess IE 8 is still officially supported, any update on this?

It is supported but with (slightly) "reduced functionality" here and there.

28599-currentcolor-arrow.diff looks good. It won't work in IE8 anyway, no support for box-shadow there.

Last edited 3 years ago by azaozz (previous) (diff)

#49 in reply to: ↑ 48 @afercia
3 years ago

Replying to azaozz:

Replying to afercia:

...I guess IE 8 is still officially supported, any update on this?

It is supported but with (slightly) "reduced functionality" here and there.

great, thanks!

It won't work in IE8 anyway, no support for box-shadow there.

I forgot to mention that :)

#50 @rianrietveld
3 years ago

Tested 28599-currentcolor-arrow.diff on focus and on hover with latest Safari, Chrome and Firefox in Yosemite. Works good.

#51 follow-up: @afercia
3 years ago

There are some small issues, for example when the menu is folded, the fly-out "triangle" should be smaller, the JS part is not needed, the SASS files need to be updated and other minor things but before going into details... idea:

the "focus bar" looks pretty bad when it's close to the fly-out triangle (1),
what about making it appear on the right only for fly-out sub items (2),
while keeping it on the left in all other cases (3 and 4)?

Designers, a11y team, and anyone's feedback welcome.

https://cldup.com/08LlA23-AS.png

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

#53 in reply to: ↑ 51 ; follow-up: @Michael Arestad
3 years ago

Replying to afercia:

the "focus bar" looks pretty bad when it's close to the fly-out triangle (1),

Yes. Yes it does. Good catch!

what about making it appear on the right only for fly-out sub items (2),

That's a thought. It's not perfect, but works and is still useful for tabbing.

while keeping it on the left in all other cases (3 and 4)?

If we put it on the right side, we should probably do it for all of them rather than just sub navs.

#54 in reply to: ↑ 53 ; follow-up: @florianziegler
3 years ago

Replying to Michael Arestad:

If we put it on the right side, we should probably do it for all of them rather than just sub navs.

Then you have the same problem with the arrow, just "inverted": the arrow would be displayed on top of the bar, which also looks kind of bad.

I tried the bar on the right side for the (flyout) submenus: It solves the problem with the triangle/arrow, but it doesn't work as well in providing the additional visual cue. It is there, but the effect is somewhat lessened by the fact that is much further away from the corresponding text.

I corrected the arrow size on the collapsed menu. (Thanks @aferica for pointing that out.)

We should discuss further tonight (rather all of you, because I am not sure, if I will be able to make it due to our local WP meetup) and then I can combine the suggestions/fixes in another patch.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#56 in reply to: ↑ 54 @afercia
3 years ago

Replying to florianziegler:

Replying to Michael Arestad:
I tried the bar on the right side for the (flyout) submenus: It solves the problem with the triangle/arrow, but it doesn't work as well in providing the additional visual cue. It is there, but the effect is somewhat lessened by the fact that is much further away from the corresponding text.

After some testing, I totally agree: on the right is less effective from an accessibility point of view.

This ticket was mentioned in Slack in #accessibility by accessiblejoe. View the logs.


3 years ago

This ticket was mentioned in Slack in #design by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #design by afercia. View the logs.


3 years ago

#60 follow-up: @valendesigns
3 years ago

I was just reading from the Trac mailing list when I came across comment 44 and wanted to jump in and let you guys know I opened ticket #30488 to address the body class not updating after a scheme change earlier today before I knew about this ticket. I think my patch might be a better place for that fix and also a slightly different approach. If we could get some traction on that patch then everyone could benefit from the change a bit earlier, as this tickets been open for a while and the missing body class should be fixed sooner rather than later. Thanks guys.

Cheers,
Derek

#61 in reply to: ↑ 60 @florianziegler
3 years ago

Replying to valendesigns:

I think my patch might be a better place for that fix and also a slightly different approach. If we could get some traction on that patch then everyone could benefit from the change a bit earlier, as this tickets been open for a while and the missing body class should be fixed sooner rather than later. Thanks guys.

Tested. Looks good to me. The sooner we get this fixed, the better.

I'll leave the respective code in my next patch for now, so that people can actually test it. Will remove once #30488 is committed.

#62 @florianziegler
3 years ago

  • Keywords ui-feedback added

There is still the issue of "focus bar in combination with the submenu arrow", as pointed out by aferica.

The only thing I could come up with, was getting some separation between the bar and the arrow, by adding a border in the same color as the arrow and (slightly) adjusting the background-color of the submenu. It looks like this:

https://cldup.com/x7Aw-3JKrS.png

Only done via in-browser editing for now. This adds a 6 pixel border to the left side of the submenu, so this might be a deal-breaker.

Please share your ideas.

This ticket was mentioned in Slack in #accessibility by accessiblejoe. View the logs.


3 years ago

#64 @afercia
3 years ago

With the separation between the bar and the arrow, it looks far better.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by rianrietveld. View the logs.


3 years ago

This ticket was mentioned in Slack in #design by joedolson. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#70 @joedolson
3 years ago

I like the look of this most recent suggestion - it seems elegant and yet very clearly visible. Would love to see a patch with this.

@florianziegler
3 years ago

Add an additional border on the left side to get some separation between the admin menu and the focus bar

#71 @florianziegler
3 years ago

I put the latest ideas into a new patch.

I hope we can get a few more people to look at this solution and decide if this is actually a viable option (from a design perspective).

Known bug: When the admin menu is folded, focusing/hovering on the current menu item, the submenu is missing the border and has a wrong background color.

#72 @SergeyBiryukov
3 years ago

  • Milestone changed from Future Release to 4.2

#73 @rianrietveld
3 years ago

@florianziegler, I like this latest design very much

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#75 follow-up: @ryan
3 years ago

Mobile screenshots, please.

Someday soon, I want submenus to go away entirely. :-)

#76 in reply to: ↑ 75 @ryan
3 years ago

Replying to ryan:

Mobile screenshots, please.

Someday soon, I want submenus to go away entirely. :-)

Related mobile chat and screenshot.

https://wordpress.slack.com/archives/accessibility/p1421870414000441

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

#78 @ryan
3 years ago

Here's a quick look at the patch in action on a Nexus 5 with a couple preliminary impressions.

https://make.wordpress.org/flow/2015/01/27/admin-menu-visual-focus-indication-28599-nexus-5/

#79 @DrewAPicture
3 years ago

  • Component changed from General to Administration
  • Focuses administration removed
  • Keywords has-patch added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by afercia. View the logs.


3 years ago

#82 @afercia
3 years ago

Waiting for UI feedback, maybe some popular "menu bars" examples can be useful for the visual part. Vertical and horizontal bars: though they're not used for the "focus" state but for the current active menu. See screenshot.
I'm not a designer but I can see there's a common detail in all of them: more space between the bar and the menu item text. White space is good :)

https://cldup.com/mVrBpoN3KD.png

This ticket was mentioned in Slack in #core by afercia. View the logs.


3 years ago

#84 @afercia
3 years ago

Spotify :)

https://cldup.com/TZSUVEeTpH.png

#85 @helen
2 years ago

Can we get some screenshots of whatever the latest iteration is in various states (expanded and collapsed, narrow screens if different there, active/focus/hover), or point me to the attachments so we can more easily solicit design feedback? It's much easier to get that feedback across the board when you don't have to apply patches and navigate around yourself :)

This ticket was mentioned in Slack in #accessibility by accessiblejoe. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


2 years ago

#89 @DrewAPicture
2 years ago

  • Milestone changed from 4.2 to Future Release

I agree with @helen in comment:85: the first thing we're going to need to move this ticket forward is screenshots with the latest iteration of the patch applied.

I think we're too advanced into the cycle to get this done right in 4.2, maybe we can tackle this early in 4.3.

Last edited 2 years ago by DrewAPicture (previous) (diff)

This ticket was mentioned in Slack in #accessibility by accessiblejoe. View the logs.


2 years ago

#91 @rianrietveld
2 years ago

  • Description modified (diff)

This ticket was mentioned in Slack in #design by helen. View the logs.


23 months ago

This ticket was mentioned in Slack in #accessibility by accessiblejoe. View the logs.


22 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


12 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


11 months ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 weeks ago

#97 @melchoyce
7 weeks ago

  • Keywords needs-screenshots added
Note: See TracTickets for help on using tickets.