Opened 12 years ago

Closed 11 years ago

#4118 closed task (fixed)

Tundra: Customize focus LnF for form widgets

Reported by: bill Owned by: dante
Priority: high Milestone: 1.2
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by dante)

Everyone seems to be complaining that the default dotted focus border looks ugly... we can't just remove it, for a11y reasons, but we can indicate focus differently.

When form widgets are focused they all have a class like dijitButtonFocused or dijitInputFocused (see [10006]). Take advantage of this to customize focus LnF to be something other than the dotted border.

Refs #3691 and #4099

Widget list:

  • Spinner (and Combobox?): needs to be fixed for border color change (like other TextBox?? widgets)
  • Slider (#3691): not sure how to do this one
  • Buttons: make focus state like hover state, but in addition to background color change, border needs to change too (for a11y reasons). Same as TextBox?? widgets.
  • tabs: see above
  • checkbox and radio (#4099): need more distinct change for checkboxes?
  • Menu: make a border with the same color as the background, so it's normally invisible, but for users that disable background-colors they can still tell which element is selected

Change History (12)

comment:1 Changed 12 years ago by Becky Gibson

There shouldn't be issues with this as long as focus actually gets set and the focus border LnF does not just rely on color (in other words focus is still visible in high contrast mode and meets color contrast guidelines).

comment:2 Changed 12 years ago by Becky Gibson

I meant to say shouldn't be a11y issues with this....

comment:3 Changed 12 years ago by bill

Owner: set to dante

More complete list:

  • Spinner (and Combobox?): needs to be fixed for border color change (like other TextBox? widgets)
  • Slider (#3691): not sure how to do this one
  • Buttons: make focus state like hover state, but in addition to background color change, border needs to change too (for a11y reasons). Same as TextBox? widgets.
  • tabs: see above
  • checkbox and radio (#4099): need more distinct change for checkboxes?

comment:4 Changed 12 years ago by bill

Description: modified (diff)

(moving list to bug description, and adding Menu to the list)

comment:5 Changed 12 years ago by bill

Description: modified (diff)

comment:6 Changed 12 years ago by Becky Gibson

Sorry, I wasn't clear in my post above. We can't just rely on color alone in any mode. High contrast is one good way to test. Thus, Menu will still need a visible border of some kind because we can't just rely on color alone in any mode. This is to help with color blindness and other color related vision issues where the person may not use high contrast mode.

comment:7 Changed 12 years ago by bill

I'm thinking and hoping that since Menu completely inverts the selection (black text --> white text, and background almost goes from white --> black) that that's a good enough solution for Menu (and for Tree... I forgot to mention Tree in my list above).

That's the way Windows works (although you can change the default behavior of windows.)

Otherwise it puts us at a big disadvantage styling-wise.

comment:8 Changed 12 years ago by dante

Status: newassigned

a _serious_ disadvantage styling-wise, but on the flip side, that's the audience we're trying to accommodate with our a11y-love ... wrt to Menu: would a border-color matching the background color (assuming the contrast is enough) suffice? It would border the element in images-off/high contrast, but afaik will still show the 1px border surrounding the focused element. (it would be hidden in the 'normal' theme-mode by matching colors)

comment:9 Changed 12 years ago by bill

Actually since we have a dijit_a11y CSS flag, we can add a border in high contrast mode without having to have a border in normal mode, so I don't think the matching color trick gets us anything.

comment:10 Changed 12 years ago by bill

Milestone: 1.01.1

This is mostly finished but a few remaining issues...

comment:11 Changed 11 years ago by dante

Milestone: 1.11.2
severity: normalminor

just a little more, though is significantly less important now.

comment:12 Changed 11 years ago by dante

Description: modified (diff)
Resolution: fixed
Status: assignedclosed

I'm going to close this as 'fixed', as a lot of work was done on this ticket. There are a host of 1.2-targeted tickets regarding visual polish, and this ticket has become too vague/generic to compete. Though we still need to focus on normalizing the form states ...

Note: See TracTickets for help on using tickets.