Re: Identifying results with color

Hi Jan
It would seem to me that we are looking at four groups of people that we
have to design for.

1) The first group are those who require no assistive technology, and can
experience the full spectrum of colours, etc.
  • for this group I would use the <mark> element, with a class assigned
per colour (e.g.: m1 = yellow; m2 = pink; m3 = etc...);
    Fully supported in Firefox, but I can't test from my current location
what the support is in IE, Chrome, Safari, etc; perhaps someone else can
throw light on this.

2) The second group of people we are designing for are those with
colour-deficiency;
  • the normal rules would apply to choose colours that will not create
confusion (this may become difficult when we get to the 10th, 11th, etc
colour, so expect some degrading of the quality of information;

3) The third group are people who require the use of high-contrast views;
and again, I can't test from my current location what high-contrast modes
will do with the <mark> element, but perhaps someone else can. If it does
not display anything then perhaps we could add dashed underlining to the
styling to enable high-contrast users to see where the search words occur,
even if they can not visually distinguish how often or where a specific
word occurs, without physically looking at each word and reviewing the
text. Perhaps the numbering of words may come in useful, but one would have
to check with actual users whether the additional number in the text will
be an aid or a hindrance. (Note: I would most definitely not want this to
appear for group 1 and 2, so would have a mechanism to show/hide this, so
that it does not cause interference for groups 1 and 2.)

4) The fourth group of people use screenreaders and would not benefit from
use of colour to distinguish terms. Your suggestion of numbers is one
possible solution, but I have concerns that this will add a high level of
'pollution' which may cause interference. Given that the user will already
be subjected to the element being announced, followed by the search
phrase/word, I'm wondering if this is not sufficient to enable users to
distinguish where the search words occur in the text. (Again, I don't have
a current copy of screenreader at my current location, but someone else may
be able to tell us what support screenreaders have for and how it announces
the element (if this is currently supported).

If however, you are trying not only to highlight and distinguish one
phrase/word from the next, but also longer groups of words from another
group of words, where the words may not even appear as a single group, but
randomly within the text, then we have to think of this from a very
different point of view, and then perhaps the number to distinguish one
group of words will be the simplest solution.

Kind regards
Harry





On 10 April 2013 20:27, Jan Eric Hellbusch <hellbusch@2bweb.de> wrote:

> Thanks, Joe,
>
> > If I understand the functionality you've explained, I can search - this
> email, for
> > example - for multiple different words. These words are highlighted in
> different
> > colours depending on the word used. So 'email' may be highlighted in
> green,
> > 'search' may be highlighted in blue - is this what you mean? And you are
> trying to
> > convey the meaning of these different highlight colours to users who may
> not be
> > able to distinguish between the colours (but who can, presumably,
> distinguish
> > highlighted from non-highlighted words)
>
> Almost. It is a complex application and there is the need to identify
> different types of content. That is why the concept for the application
> allows multiple colors for highlighting. The application will need to be
> accessible to users with visual impairments and they may be using a
> contrast
> mode (Windows) and then not be able to distinguish between marked and
> unmarked text. The text would be given a background color, which is ignored
> in contrast mode.
>
> > If so, the word itself would seem to be the distinguishing feature - A
> quick glance
> > at the page and I see lots of blues and greens around the page indicating
> > highlighted results, but even if I can't distinguish these shades from
> one
> another
> > (but can see that certain words are highlighted), all I need to is read
> the
> > highlighted words to distinguish them - I don't need the number 1
> prefixed
> to the
> > word 'search' to tell the difference between that and another highlighted
> search
> > result 'email' as I can simply read the words. In which case, I don't see
> that you
> > need do anything involving numbers or other identifying features.
>
> In a simple (one color) highlighting scheme there are plenty of
> possibilities to conform to 1.4.1, for example giving a marked text a
> border
> with the same color. When background is ignored in contrast mode, the
> border
> will be shown in the text color and is usually perceivable. With two or
> even
> three different colors there are further possibilities to distinguish
> marked
> strings through text formating. But considering ten and more colors I don't
> see a good solution using text formatting alone. That is why we are
> considering adding numbers (or other characters) to the highlighted text.
>
> > To semantically identify these results as being highlighted, for
> screenreader users
> > for instance, you can use the HTML5 <mark> element, presumably with
> different
> > classes for different search result terms.
>
> Thanks. We will look into that. Is there any information on screenreader
> support for that element?
>
> Jan
>
>
> --
> Jan Eric Hellbusch
> Tel.: +49 (231) 86436760 oder +49 (163) 3369925
> Web: http://2bweb.de     Twitter: www.twitter.com/2bweb
> --
> Das Buch über barrierefreies Webdesign:
> "Barrierefreiheit verstehen und umsetzen - Webstandards für ein
> zugängliches
> und nutzbares Internet"
> 812 Seiten, Dpunkt Verlag (2011)
> http://www.barrierefreies-webdesign.de/dpunkt/
>
>
>
>
>