Fwd: [w3c/wcag21] Interactive Element Contrast (Minimum) (LV) !! ready for review (#10)

---------- Forwarded message ----------
From: Wilco Fiers <notifications@github.com>
Date: Wed, Nov 23, 2016 at 5:43 AM
Subject: Re: [w3c/wcag21] Interactive Element Contrast (Minimum) (LV) !!
ready for review (#10)
To: w3c/wcag21 <wcag21@noreply.github.com>
Cc: allanj-uaag <jimallan@tsbvi.edu>, Author <author@noreply.github.com>


I have a few issues and questions. Hope this helps!

important (non-text) information in an interactive image;


   -

   I think the scope of this should be changed. It makes sense for me that
   if you have an interactive bar graph, that the color contrast requirement
   there is different from that of a static image. But the way this criterion
   is formulated it's already applicable if this static image was part of a
   link. This feels pretty arbitrary. Not sure how to properly describe this,
   but I would exclude things like plain image links from this.
   -

   Remove () from non-text to make it clear this is only about non-text.
   This scope must be limited to non-text information, as the usual exceptions
   that apply to the color contrast rule aren't in this criterion.

input elements or the border line(s) of input elements;


   -

   I don't think border should be mentioned separately. This implies that
   the other 2 bullets wouldn't pass if they were done through border
   -

   Input elements is the wrong word here. I'm guessing this to be similar
   to what 4.1.2 calls "form elements". Although I'm not a fan of that either.
   For sure input element excludes textarea and select if you take a narrow
   interpretation of this. So maybe form control? I'm guessing this applies to
   buttons too?

focus and select indicator(s).


   -

   This seems strange to me, select indicators are often done with a
   background color. Does this mean the background color has to have a
   contrast of 4,5:1 to the non-selected parts? That seems wrong to me. For
   thick stroke you allow 3:1, but backgrounds still require 4,5:1? I would
   think a background change is at least as clear as a thick border.
   -

   Additionally, this 4,5:1 requirement almost forces you to invert the
   text color on selected items. If you have a select element for example, the
   BG is #FFF and the text is #555 (a respectful 7.5:1). Now an option is
   selected, and it gets a background of #777 so that it has a 4,5:1
   difference to the #FFF bg. The text of #555 has to change color because on
   a #777 bg it no longer meets 4.5:1. If you do not actually want to change
   the text color when you select (which you may not want because that can be
   a little jarring), the actual color contrast requirement becomes 9:1!
   (Reminder 12:1 is the difference between black and white.)
   -

   Many browsers have a default dotted border. Am I right in guessing that
   as long as that dotted line has a color of 4,5:1 it meets this?

thicker lines: where the minimum width of the line is at least 3px;

I think these criteria should use PT instead of PX. It's a bit of a messy
unit. If you have 3px on an LDPI screen, that's the same width as 12px on
an XXDPI screen. CSS normalizes these values, calculating them to something
like whatever the size would be if the screen was 72 DPI. But that just
adds to the confusion. PPK has a great article about why CSS PX isn't the
same as pixel width. http://www.quirksmode.org/
blog/archives/2010/04/a_pixel_is_not.html

3:1 Exceptions:
disabled interactive elements;

This may be a personal preference thing, but having low vision, I think
it's much more important that there is a clear difference between active
and disabled elements, rather than ensure that disabled elements have a
strong contrast with their background. To me, this requirement can actually
reduce accessibility, as the minimum contrast for disabled elements would
mean it will become harder for me to tell them apart from active elements.

disabled interactive element

Should this include 'inactive' links?

Important information
information the user may need to complete any action or task including an
offline task.

This is a pretty open ended requirement. Not sure how to word it, but I
would think this should be limited to actions / tasks that is part of
functionality available on the current page, or on a page in a process that
the current page is part of.

The term "graphical element" is intended to apply to stand-alone icons such
as a print icon...

I'm guessing this is a dated term, as it doesn't show in the success
criterion text anymore? Should it be removed?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/w3c/wcag21/issues/10#issuecomment-262492655>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AG_WL3ratsfjMU3RXOV75-9c5wKQeeiVks5rBCbbgaJpZM4J-Rwz>
.



-- 
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964