- From: Erich Manser <emanser@us.ibm.com>
- Date: Tue, 29 May 2018 12:46:32 -0400
- To: Jim Allan <jimallan@tsbvi.edu>
- Cc: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
- Message-Id: <OFA9359502.18941DFD-ON8525829C.005BCE2C-8525829C.005C26CB@notes.na.collabserv.c>
I am fine with gestalt. I am comfortable with having flexibility in the SC
to allow for buttons not having highly apparent borders, as my experience
is that buttons can generally also be identified contextually based on
surroundings.
Erich Manser
IBM
Accessibility,
IBM Research
Littleton,
MA / tel:
978-696-1810
Search for
accessibility
answers
You don't need eyesight to have vision.
From: Jim Allan <jimallan@tsbvi.edu>
To: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Date: 05/29/2018 10:53 AM
Subject: Fwd: Resolving 1.4.11
Low Vision Folks. Need thoughts. Jon and Wayne have spoken up. There is a
question about the gestalt of borders and boundaries. I can live with
that.
Please give this a read and comment.
Jim
---------- Forwarded message ---------
From: Andrew Kirkpatrick <akirkpat@adobe.com>
Date: Sat, May 26, 2018 at 5:46 PM
Subject: Resolving 1.4.11
To: WCAG <w3c-wai-gl@w3.org>
AGWG’ers,
**WARNING – lengthy but important and time-critical email!**
We have a few concerns raised about 1.4.11 Non-text contrast:
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.
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 of the following have a contrast ratio of at least
3:1 against adjacent color(s):
User Interface Components
Visual information used to indicate states and boundaries of 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 to the information
being conveyed.
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.
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.
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.
Github buttons #2. The contrast everywhere is sufficient except in
the thin border line around the not-currently-selected items.
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.
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.
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.
LevelAccess – high-contrast throughout.
Funka. Active/selected tab shows sufficient contrast for state. The
non-selected tabs don’t use color to indicate the boundaries.
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.
Funka search open. Once the search button is open, everything seems
to have suffient 4.5/3:1 contrast.
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.
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.
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.
Buttons with specific boundaries – contrast between states is 1.75:1,
so to some people this just looks like one green area.
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.
Bootstrap checkbox. The checkbox is 1.30:1 contrast relative to the
background.
https://getbootstrap.com/docs/4.1/components/forms/#inlineFormCustomSelect
Interpretation:
My interpretation of the SC, and what I believe that the WG intended is
that:
Visual information that is important to identifying the state or
existence (boundary) needs to be at least 3:1.
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.
For some components, text that is 4.5:1 is entirely sufficient to
meet the requirements of 1.4.11.
Are we requiring a full boundary around links (which are UI
Components)? I don’t believe so.
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.
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.
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.
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:
Pass
Borderline fail – perhaps an uncomfortable pass?
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Pass
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.
Pass
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?
Fail – the contrast for the boundary is particularly significant in
this situation.
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.
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
--
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.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
[attachment "image001.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image002.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image003.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image004.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image005.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image006.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image007.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image008.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image009.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image010.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image011.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image012.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image013.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image014.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image015.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image016.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image017.png" deleted by Erich Manser/Cambridge/IBM]
[attachment "image018.jpg" deleted by Erich Manser/Cambridge/IBM]
[attachment "image008.png" deleted by Erich Manser/Cambridge/IBM]
Attachments
- image/jpeg attachment: 4C214475.jpg
- image/jpeg attachment: 4C706290.jpg
- image/gif attachment: ecblank.gif
- image/gif attachment: 4C590436.gif
- image/gif attachment: graycol.gif
Received on Tuesday, 29 May 2018 16:47:10 UTC