Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#34876 closed defect (bug) (fixed)

#a11y-color: "Add New" buttons on edit screens do not have CSS :focus states

Reported by: adamsoucie's profile adamsoucie Owned by: michaelarestad's profile michaelarestad
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.4
Component: Administration Keywords:
Focuses: accessibility Cc:

Description (last modified by SergeyBiryukov)

There are no CSS focus states/pseudo selectors on the "Add New" buttons on edit screens.

Currently working on a patch to just extend the current hover states to also trigger on :focus.

Keeping this issue separate from #34864 because ultimately the color could be a new design decision, but extending :hover to :focus would be continuing an already established design decision.

Attachments (1)

add-new-button-focus.34876.diff (378 bytes) - added by adamsoucie 10 years ago.
Extends the current :hover state to :focus on .wrap .page-title-action

Download all attachments as: .zip

Change History (16)

@adamsoucie
10 years ago

Extends the current :hover state to :focus on .wrap .page-title-action

#1 @Cheffheid
10 years ago

Patch works for me. New focus state for these buttons looks like the hover style.

http://i.imgur.com/G6x9Xkn.png

#2 @michaelarestad
10 years ago

I think this likely will be addressed at the same time as #34864. I wouldn't use the same styles as the hovers in favor of just using a nice box shadow and maybe a border highlight. I'd like to propose a subtle border in #34864.

#3 @michaelarestad
10 years ago

  • Owner set to michaelarestad
  • Resolution set to fixed
  • Status changed from new to closed

In 35791:

Administration: Improve color contrast of 'Add New' buttons.

This also includes improved focus styles for 'Add New'.

fixes #34876, #34864.

#4 @adamsoucie
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

After continued discussions with the a11y team, we disagree with the decision and feel it is far simpler to echo the :hover to :focus. What is the logic against mirroring :hover, when :hover, it can be argued, is actually an extension of :focus?

@mor10's comments on 34864 come into play here as well. The text change is way too subtle (as is the case throughout the admin's :focus states). There needs to be a very clear visual shift (as we do with :hover).

#5 @michaelarestad
10 years ago

The text change is way too subtle (as is the case throughout the admin's :focus states).

There is only a text change on this particular "button." On the main button styles, there is no change. On links, there is a very subtle color change. I would rather this change similar to the link, if any.

What is the logic against mirroring :hover, when :hover, it can be argued, is actually an extension of :focus?

Good question! @mor10 and I did a little debate on this in person last night. There is a subtle difference in context between hover and focus. Hover is definitely an extension of focus, but there is an added separate context in hover versus focus. Hover is something used to show where the cursor is and that an element is indeed interactive.

The biggest visual change needs to happen on focus for sure. I think a subtle difference between hover and focus is totally fine. In this case, I think the current drastic change for hover is pretty extreme since it basically inverts everything (super extreme and unlike any other element in WordPress).

My current recommendation would be to drastically reduce the visual impact of the hover state, but want to explore that in another ticket. I think this link, its design, and its location could be improved. I think my changes do resolve this ticket pretty nicely without going too far with design changes yet. Another route would be to go further away from button styles and go toward standard link styles, though I think those aren't as nice looking and might not stand out as much as they should.

@adamsoucie Any objections to closing this and instead creating a ticket to do a more wholistic design/location iteration of the link?

#6 @adamsoucie
10 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

@michaelarestad None at all. I was able to speak with @mor10 yesterday about how this is actually a larger issue we need to address and would love to work on it with you. Glad we could resolve this! I look forward to the continued collaboration!

Is there already a ticket for the wide-spread update, or does one need to be created?

#7 @swissspidy
10 years ago

  • Milestone changed from Awaiting Review to 4.5

#8 @michaelarestad
10 years ago

Is there already a ticket for the wide-spread update, or does one need to be created?

@adamsoucie There is no ticket yet that I'm aware of.

#9 @adamsoucie
10 years ago

@michaelarestad @mor10 Happy to create one. Let's find some time soon to come up with a plan :)

#10 @johnbillion
10 years ago

  • Resolution changed from worksforme to fixed

#11 @SergeyBiryukov
10 years ago

  • Description modified (diff)

#12 @johnbillion
10 years ago

  • Version changed from trunk to 4.4

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


10 years ago

#14 @afercia
10 years ago

For reference: discussion about the focus style continues on #34904 and #34957.

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


10 years ago

Note: See TracTickets for help on using tickets.