Re: Resolving 1.4.11

> Or does the lack of visual information for *all *users about the input
mean this is a design issue, not an accessibility issue?


Like David and Detlev, I also agree with this statement (i.e. it ain't
great for *anyone*, but is a design issue as it impacts everyone, and not
just a sub-group).

> I don't think we can say visual cues are necessary to pass this SC, but
if  cues *are* used that are required to identify the component, then they
need to be 3:1.


Precisely, and this has been my understanding of this SC for some time now.

However as David notes we have 'eased up' a fair bit from where we were
previously, but like David, I don't see that as a bad thing (although as my
colleague Wilco has observed, we've now also made this a manual as opposed
to automated test, given the added amount of subjectivity we injected).

JF

On Wed, May 30, 2018 at 1:57 PM, David MacDonald <david100@sympatico.ca>
wrote:

> >  Would people would fail it for lacking visual identifying
> characteristics on an input? Or does the lack of visual information for
> *all *users about the input mean this is a design issue, not an
> accessibility issue?
>
> I don't think we can say visual cues are necessary to pass this SC, but
> if  cues *are* used that are required to identify the component, then they
> need to be 3:1.
>
> The Funka example ... the placement of the buttons is consistent with a
> menu and they are laid out as a nav menu would be, so under our discussion
> of interpretation yesterday I would not fail it...
>
> I admit the SC now has a lot of room for interpretation from evaluators,
> but that's better than forcing a border around everything.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Wed, May 30, 2018 at 2:20 PM, Michael Gower <michael.gower@ca.ibm.com>
> wrote:
>
>> I wasn't sure whether to bring this up on the CFC or in this thread, but
>> I would like to understand whether the first example you gave, the
>> Knowbility <https://knowbility.org/>Search mechanism, would be
>> considered to pass the rewording of 1.4.11.
>> To me, this lacks any visual indication that it is an input field. It is
>> indistinguishable from the links immediately below it. The new SC wording
>> states "Visual information required to identify user interface
>> components" needs to meet a 3:1 ratio.
>> Would people would fail it for lacking visual identifying characteristics
>> on an input? Or does the lack of visual information for *all *users
>> about the input mean this is a design issue, not an accessibility issue?
>> I also want to understand whether folks think Funka's questions about
>> their buttons have been resolved with this new change. Is each button's
>> shape, defined by a flat colour, part of the visual information required to
>> ID each as a button?
>> Is it up to the tester to make that call, and thus decide whether the
>> button color needs to meet 3:1?
>>
>> We just had specific questions on a call here at IBM about some new
>> low-contrast UI components, and whether we had leeway to fail them with the
>> new wording or had to find some other means of convincing the designers to
>> rethink the components.
>>
>> Michael Gower
>> IBM Accessibility
>> Research
>>
>> 1803 Douglas Street, Victoria, BC
>> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC++V8T+5C3&entry=gmail&source=g>
>>  V8T 5C3
>> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC++V8T+5C3&entry=gmail&source=g>
>> gowerm@ca.ibm.com
>> cellular: (250) 661-0098 *
>> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC++%C2%A0+V8T+5C3&entry=gmail&source=g>fax:
>> (250) 220-8034
>>
>>
>>
>> From:        Andrew Kirkpatrick <akirkpat@adobe.com>
>> To:        WCAG <w3c-wai-gl@w3.org>
>> Date:        2018-05-26 03:46 PM
>> Subject:        Resolving 1.4.11
>> ------------------------------
>>
>>
>> AGWG’ers,
>>
>>
>>
>> **WARNING – lengthy but important and time-critical email!**
>>
>>
>>
>> We have a few concerns raised about 1.4.11 Non-text contrast:
>>
>>
>>
>> 1.        Concern from Funka (see Word doc attachment at
>> https://lists.w3.org/Archives/Public/public-comments-wcag20/
>> 2018May/0001.html) that the Color limitations for buttons with text on a
>> colored background are too limiting. People either won’t be able to use
>> yellow or will need to use an extra border and that will be unpopular for
>> designers. This is the same issue as the concern about boundaries in Issue
>> 914: *https://github.com/w3c/wcag21/issues/914*
>> <https://github.com/w3c/wcag21/issues/914>.
>>
>> 2.        Does the hover state indicator need to have 3:1? (Issue 913:
>> https://github.com/w3c/wcag21/issues/913)
>>
>>
>>
>> *So, what do we do? I think that it helps to look at a bunch of examples:*
>>
>>
>>
>> As a reminder, this is the SC text:
>>
>> 1.4.11
>>
>> The visual *presentation*
>> <https://www.w3.org/TR/WCAG21/#dfn-presentation>of the following have a *contrast
>> ratio* <https://www.w3.org/TR/WCAG21/#dfn-contrast-ratio> of at least
>> 3:1 against adjacent color(s):
>>
>> *User Interface Components*
>>
>> Visual information used to indicate *states*
>> <https://www.w3.org/TR/WCAG21/#dfn-states>and boundaries of *user
>> interface components*
>> <https://www.w3.org/TR/WCAG21/#dfn-user-interface-components>, except
>> for inactive components or where the appearance of the component is
>> determined by the user agent and not modified by the author;
>>
>> *Graphical Objects*
>>
>> Parts of graphics required to understand the content, except when a
>> particular presentation of graphics is *essential*
>> <https://www.w3.org/TR/WCAG21/#dfn-essential>to the information being
>> conveyed.
>>
>>
>>
>>
>>
>> 1.        Knowbility’s search box. There is 4.5:1 text that indicates
>> that there is something for the user to activate. It is a search box and
>> when you click on it the placeholder text shifts to the left and exposes
>> the full area of the input.
>>
>>
>>
>>
>>
>> 2.        Github’s tab interface. It is pretty clear which tab has the
>> selected state because of the red accent, but there is definitely not 3:1
>> contrast between the background colors of “code” and “issues”, nor is the
>> line between these 3:1.
>>
>>
>>
>> 3.        Github buttons. For the “unwatch” button, the contrast between
>> the inside of the button and the outside is 1.08:1, and between the border
>> line and the outside background is 1.62:1. The contrast between the unwatch
>> text and the little triangle that indicates the drop down is 13.79:1.
>>
>> 4.        Github buttons #2. The contrast everywhere is sufficient
>> except in the thin border line around the not-currently-selected items.
>>
>> 5.        New WAI site. The difference in contrast between a hovered
>> item and a non-hovered item in the nav is 1:40:1, but there is a
>> high-contrast underline that is also part of the hover.
>>
>> 6.        CNN. Contrast of hovered and non-hovered text is greater than
>> 4.5:1. Contrast between the hovered and non-hovered text is 1.84:1.
>>
>>
>>
>> 7.        Adobe. The light gray background appears on hover and the tiny
>> little triangle appears. The text has sufficient contrast in hover and
>> non-hover states, but the hover background and triangle don’t.
>>
>>
>>
>>
>>
>> 8.        LevelAccess – high-contrast throughout.
>>
>>
>>
>>
>>
>> 9.        Funka. Active/selected tab shows sufficient contrast for
>> state. The non-selected tabs don’t use color to indicate the boundaries.
>>
>>
>>
>> 10.        Funka Search. The three items in the top nav – the left two
>> don’t use color to indicate the boundary. The right button does but the
>> contrast isn’t 3:1.
>>
>> 11.        Funka search open. Once the search button is open, everything
>> seems to have suffient 4.5/3:1 contrast.
>>
>>
>>
>> 12.        Material design. Text fields come in two forms. The example
>> on the left has a field background that is less than 3:1 with the
>> background, but the line marking the bottom boundary of the field is 3.28:1
>> on the background. For the triangle in the drop down the ratio is 3.02:1
>> relative to the field background.  On the right, the border has a 3.64:1
>> ratio to the background, but it goes all the way around.
>>
>>
>>
>> 13.        Material design selection. The selected item on the left has
>> a greater than 3:1 ratio for the checked/unchecked box, but the purple
>> background is not 3:1. On the right, the purple activated color has >6:1
>> contrast against the light purple and >7:1 against the white, but the
>> purple background is less than 3:1 against the white.
>>
>>
>>
>> 14.        GoFundMe donate page: The “your name” label text (not
>> properly labeled) is >4.5:1, but the field border and placeholder text are
>> less than 3:1.
>>
>> 15.        Buttons with specific boundaries – contrast between states is
>> 1.75:1, so to some people this just looks like one green area.
>>
>>
>>
>> 16.        Facebook marketplace active area indicator. The greatest
>> contrast is the whitish background of groups and the thin border between
>> that and the light grey background. 1.22:1 contrast.
>>
>>
>>
>> 17.        Bootstrap checkbox. The checkbox is 1.30:1 contrast relative
>> to the background.
>>
>>
>> *https://getbootstrap.com/docs/4.1/components/forms/#inlineFormCustomSelect*
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgetbootstrap.com%2Fdocs%2F4.1%2Fcomponents%2Fforms%2F%23inlineFormCustomSelect&data=02%7C01%7Cakirkpat%40adobe.com%7C05736cdf6373468230e408d5c31ae33d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636629442639781231&sdata=TMFTI316LNA3T8bUUPXyKIZFx7xFqdw5wbyvsbke4Tw%3D&reserved=0>
>>
>>
>>
>>
>>
>>
>>
>> *Interpretation:*
>>
>> My interpretation of the SC, and what I believe that the WG intended is
>> that:
>>
>> 1.        Visual information that is important to identifying the state
>> or existence (boundary) needs to be at least 3:1.
>>
>> 2.        All visual aspects of a UI Component at not required to meet
>> 3:1, only if it is required to identity the state or existence of the
>> control.
>>
>> 3.        For some components, text that is 4.5:1 is entirely sufficient
>> to meet the requirements of 1.4.11.
>>
>> a.        Are we requiring a full boundary around links (which are UI
>> Components)? I don’t believe so.
>>
>> b.        Are we ok with a set of tabs like in example #9 above, or does
>> each tab need a full boundary to indicate the click area? I believe so.
>>
>> 4.        If a color is less than 3:1, you need to pretend that it
>> doesn’t exist at all and assess whether the component passes based on other
>> information.
>>
>> a.        Compare the same set of tabs in example #9 and consider
>> whether it is less accessible if the non-active tabs have a pale color
>> background.
>>
>> 5.        Hover is covered, but not relative to the component’s own
>> non-hover state. What is covered is that the hover state needs to meet the
>> 3:1 ratio for any non-text content. This means that if there is an icon in
>> a button that fades out when hovered, it would fail (just like is the case
>> for 1.4.3 if text in a hovered button fades on hover).
>>
>>
>>
>> *With my interpretation the examples above are rated:*
>>
>> 1.        Pass
>>
>> 2.        Borderline fail – perhaps an uncomfortable pass?
>>
>> 3.        Pass
>>
>> 4.        Pass
>>
>> 5.        Pass
>>
>> 6.        Pass
>>
>> 7.        Pass
>>
>> 8.        Pass
>>
>> 9.        Pass
>>
>> 10.        Pass
>>
>> 11.        Pass
>>
>> 12.        Pass – the right side example passes easily. The left side,
>> with the underline border is, I think, an uncomfortable pass. Like a lined
>> paper form, people can figure out the rough size of the fields by proximity
>> and spacing, so one line is minimally sufficient.
>>
>> 13.        Pass
>>
>> 14.        Is interesting – this example clearly fails, but if the
>> control was properly associated with the label would that help since that
>> creates a clickable region that has sufficient contrast and then the
>> control becomes more visible when focused because of the focus rectangle or
>> input carat?
>>
>> 15.        Fail – the contrast for the boundary is particularly
>> significant in this situation.
>>
>> 16.        Fail – the contrast for the selected state. This is an
>> example of communicating information by color alone and the contrast
>> doesn’t make up for the color.
>>
>> 17.        Fail - Similar to #14. Some might argue that if the label is
>> properly associated that this makes the text label and image part of one
>> control and therefore ok, and we should be clear about that in a technique
>> or failure.
>>
>>
>>
>> If you find that you are agreeing that my interpretation reflects the
>> intent of the Working Group, or that you are disagreeing that it reflects
>> the intent of the Working Group, please say so.
>>
>>
>>
>> I have a pull request that implements changes in the Understanding
>> document in line with this: https://github.com/w3c/wcag21/
>> pull/943/files?utf8=✓&diff=split
>>
>>
>>
>> *Is there a downside?*
>>
>> One of the comments we received requested that we implement a requirement
>> for a thicker boundary around components. This would unquestionably help
>> people, but also creates problems in that we are specifying UI Components,
>> including links and other interactive controls. Are we requiring that
>> individual items within a select/drop down show clear boundaries since each
>> is a separate clickable region? Both of these come into play if the strict
>> interpretation of this SC is the intent of the group.
>>
>>
>>
>> I believe that we need to be unified and clear about this SC’s
>> interpretation, and soon!
>>
>>
>>
>> AWK
>>
>>
>>
>>
>>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion