Sunday, January 8, 2012

Acessibility: Contrast, colors, and fonts

As part of the goals for the current rewritings and refactorings of Polly, I'm trying to neglect accessibility a little less than I did until now. Because GTK offers great a11y support by default, this basically means taking some extra care when I edit widgets on my own instead of relying on the theme. One such care involves playing well with high-contrast themes.

Instead of a one-size-fits-all design, that would inevitably lead to some lowest common denominator aesthetic choices, the next versions of Polly will allow a --contrast command-line parameter that causes some subtle changes in the interface.

One of those changes involves the color of the error bar. In normal mode, it simply has our good old universal error color, red.


In contrast mode, the red is replaced by a color taken directly from the theme, ensuring readability while still drawing attention. Below you can see what how contrast mode looks when using the HighContrast and HighContrastInverse themes.


The other change I have implemented involves a new feature: I am going to introduce optional background color coding for unread items and mentions.


In contrast mode, where the choices of color are much more limited, I offer an alternative: marking unread items with bold and marking mentions with italic. This wasn't a very hard choice, since bold is a very common way of showing unread items in mail clients.

So when contrast mode is enabled, this is how the preferences window looks like.


What do you think? I'm not an accessibility expert, so I would love some feedback.

6 comments:

  1. An alternative approach would be to use a radio menu for each: “Highlight unread items:” and “Highlight items mentioning you:”. Each menu could contain items for a few nice colors, then “Other Color…”, a separator, “Bold”, “Italics”, another separator, and “None”.

    That would be visually as simple as the --contrast mode, and simpler than the normal mode, and it would also obviate the modes altogether.

    ReplyDelete
  2. @mpt

    The idea sounds interesting, but I didn't understand from where those menus will pop from in the preferences window. Something like a combo box?

    ReplyDelete
  3. Ah, the age-old GtkComboBox confusion.

    What I call a radio menu (Microsoft calls it a “drop-down list”, Apple a “pop-up menu”) is a menu from which one and only one item can be chosen at a time. Like a set of radio buttons in menu form.

    A combo box gets its name from the fact that it’s a combo of a text field, and an adjacent menu, drawn in the same box.

    GTK refers to a radio menu as a “GtkComboBox”, and an actual combo box as a “GtkComboBox with has-entry=true”. GTK is wrong. But it’s the sort of mistake that’s hard to fix.

    ReplyDelete
    Replies
    1. Ah, ok. I also keep forgetting that the GtkComboBox can contain things other than text labels (like separators). The idea seems fine, I'm probably going to try it.

      Delete