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

Hi Jim,

Yes. It discussed this Tuesday's WCAG WG meeting.
https://www.w3.org/2016/11/29-wai-wcag-minutes.html#item03

Glenda, Wilco, Alastair, and I are meeting next Wednesday to work things out.

Lots of comments in the WCAG WG survey too.
https://www.w3.org/2002/09/wbs/35422/NewSC_20161122/results

Kindest Regards,
Laura

On 12/1/16, Jim Allan <jimallan@tsbvi.edu> wrote:
> ---------- 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
>


-- 
Laura L. Carlson

Received on Thursday, 1 December 2016 15:54:04 UTC