Shadows & Outlines
Accessibility of component styling
mdgilbert@ (UXR), philippec@ (VisD), kunaldpatel@ (IxD) – Material
skyortiz@ (VisD) – G Suite United
jkozenski@ (UX Lead) – Core Accessibility
Q4 2018 / Q1 2019
WCAG Report
Agenda
Introductions, Goal
1
Shadows & Outline Study
2
Opportunities & Next Steps
3
Introductions
Material Design
Core Accessibility
G Suite United
Today’s Goal
What I’m hoping to accomplish today
First – to share our recent research on Shadows & Outlines (component styling for buttons and chips)
Second – to determine if the results of that study can be useful to WCAG efforts
Third – to determine, for future studies, how we might most beneficially provide actionable results to WCAG
Shadows & Outlines
Study Details
Study Goal
Establish guidelines for identifiable and interactable Material components
The primary goal of this study was to evaluate how the contrast ratios of outlines or shadows around components like chips and buttons for both desktop and mobile contexts impact the perception of those components by low vision users – their identifiability and perceived interactability.
In short, we aimed to evaluate how contrast ratios of component styling impact how our users perceive these components (emphasizing the experiences of our low-vision users), and how they might interact with them.
Guidance exists for the contrast ratio required for text
These guidelines require a contrast ratio of 4.5:1 to meet AA standards (3:1 for large text), or 7:1 to meet AAA standards (4.5:1 for large text). These guidelines are relatively clear and fairly well understood.
Background
Contrast guidance for non-text is less clear
These guidelines state that “User Interface Components” and “Graphical Objects” must have a contrast ratio of at least 3:1 to adjacent colors to meet contrast requirements.
“User Interface Components” are defined as “a part of the content that is perceived by users as a single control for a distinct function” (link to WCAG definition of user interface components). Guidelines state that the contrast ratio applies for characteristics of components (1) required to identify the component, and (2) required to identify the state of that component.
“Graphical Objects” are defined as the “Parts of graphics required to understand the content” (link to WCAG definition of graphical objects)*.
Background
Interpreting existing guidelines for our components
Finally, what does this mean for our components? What are the characteristics that define our components, and the accessibility standards those components could meet once defined? From the existing guidelines, we suggest the following standards for our buttons and chips, tested through the course of this study:
Background
Study Goal – Tl;dr
Determine if components are identifiable
1
Determine if components are perceived as interactable
2
18 participants were recruited through Google’s A11y Trusted Tester panel
3 participants dropped due to scheduling conflicts
15 participants completed at least one of three scheduled interview sessions
Interviews were held once a week with every participant for 3 weeks
36 separate interviews were completed over three weeks, for a total of 18 hours spent with our study participants
Study Setup
Comparison
Shown 3 mocks differing only in contrast, what did participants notice (or not notice)?
Speaks to:
Differentiability of components - focus on identifiability
Task
Shown a single mock and given a simple task, was that task completed reasonably easily?
Speaks to:
Differentiability of components - focus on identifiability & interactability
Ranking
Shown pairs of randomly selected prototypes, what attribute styles did participants prefer?
Speaks to:
Preference, and highlighting design attributes impacting identifiability and perceived interactability
Study Setup
Findings
1
2
On Identifiability – All participants were able to identify and differentiate between controls, regardless of control, regardless of decoration, regardless of decoration contrast (given enough time, and magnification)
On Interactability – Two participants suggested components with no outline/shadow may not be interactable*, all other participants were able to suggest possible interaction patterns.
Observed | Implication / Interpretation | Recommendation |
All participants were able to identify buttons or chip components, given enough time or magnification, regardless of [Standard], [High], or [None] contrast conditions. | Users ability to identify possible components is more robust than existing WCAG guidelines currently account for. What constitutes successful identification, and the constraints of its context, is currently too ambiguous to provide direct, useful, and actionable guidance for designers and developers. | Recommendation 1: WCAG 1.4.11 (link) – Include details to “identify” components. Clearer operationalization to avoid duplication of research effort, and to provide a well-lit path for designers and developers to consider the right problems. |
Two participants suggested [None] controls may not be interactable (one buttons, one chips), and one participant suggested [Standard] contrast looked disabled when side-by-side with [None] and [High]. All participants suggested that the above wouldn’t be a problem - they would just tap the component anyway. | Similar to identifiability, perceived interactability is the result of a combination of factors, primarily including the context in which components are deployed (e.g., Attributes). Beyond those attributes, however, whereas identifiability implies a snapshot, interactability implies an act. Where the immediate perception may be incorrect, the desired interaction was still reached. | Recommendation 2: WCAG 3.2.4 (link) already provides guidance for consistent navigation, which would ameliorate the problem we identified w/r/t state confusion (an artifact of our study design). However, continuing from identifiability as a snapshot, interactability as an act – additional guidance could be given encouraging discoverable by default, or recoverable by design, to account for the exploratory nature of observed interactions (that is, accounting for how users actually interact with content). |
Beyond the border style (e.g., [Stroke] vs [Shadow]) or border contrast ([None], [Standard], [High]), there are multiple characteristics related to the identifiability and perceived interactability of components. | The stroke or shadow outline is not the sole critical characteristic to focus on w/r/t identifiability, regardless of contrast. Taken alone, it may increase the speed of findability of the component or scannability of the page. But it is one of many attributes responsible for identifiability. | Recommendation 3: WCAG 1.4.11 (link) – Provide greater clarity and examples with regard to the “Visual information” required to identify components. Guidance at a superficial level can include more detail on the characteristics (e.g., [Attributes]) impacting identifiability. Detailed guidance may include the extent to which each characteristic is responsible for impacting findability - left for future work. |
Recommendations
Notes on Recommendation #1 | Notes on Recommendation #2 | Notes on Recommendation #3 |
Identification needs to be more clear - both in terms of inputs to the interaction (e.g., time allotted, assistive technologies allowed, etc) and the required outputs (e.g., operationalize identifiability, publicly, and document that requirement). Our definition involved ensuring the participant could (first) identify the component in the larger context of an application, and that (second) they could differentiate that component from surrounding components. This can be questioned, debunked, expanded, or adopted, but guidance should be more clear. | Identification of states (and identification more broadly, as we saw) is frequently done through a process of probing, trial and error, and generally with a spirit of experimentation where occasional failures or frictions are surmountable due primarily to their predictability. And yet, the design of interactions engendering those frictions will typically still operate under the assumption that the happy path (ref link) is the only option. From experience, from observation, and from common sense, we know that this is not always true. Accordingly I would encourage guidance that not only accounts for friction, deviations from that happy path, but expects it. That is, the addition of a section that moves towards encoding principles for discoverability by default or recoverability by design. This may be the most ambitious of our recommendations, in that it is suggesting a new pattern rather than greater details. Design guidance will be required to give shape to what this pattern may entail [[ Next steps ]], but existence of the pattern can in the interim be added to guidelines. | Our research clearly indicated that there are multiple attributes related to the identifiability and perceived interactability of components. The addition of those attributes to WCAG guidelines would concisely and immediately provide greater context to designers and developers around what characteristics of components they may consider to increase the identifiability of their components – and conversely, what characteristics they may need to beware of negatively impacting the identifiability of those components. Future work could additionally push towards a quantification of how much each of those characteristics may impact the identifiability and perceived findability of components. |
Recommendations
Recommendation
WCAG 1.4.11 (link) – Provide greater clarity and examples with regard to the “Visual information” required to identify components.
Recommendation
WCAG 3.2.4 (link) Provide additional guidance to encourage discoverable by default, or recoverable by design, to account for the exploratory nature of observed interactions.
In context
Opportunities & Next Steps
Implications for WCAG
Next Steps
Three main questions to think about tackling
Appendix
Findings in detail
20
Details
Identifiability of components
Identifiability
Note: Identifiability was defined as satisfying two criteria:
On the identifiability of components, varying style and contrast:
In every instance, participants were able to identify and distinguish between potential actions on our mocks.
However, ease of identification is dependent on multiple attributes, with more details on those attributes on slide 11.
To increase the usability of an experience, we should consider not just the contrast of component decoration (e.g., shadows and outlines), but the collection of attributes perceived as most salient in component identification.
21
On the interactability of components, varying style and contrast:
While components were nearly uniformly considered identifiable, there was occasional confusion on perceived interactability.
The lack of any component decoration (e.g., stroke or shadow) led some participants to question the interactability of that component.
Note that, in our sessions, given enough time and magnification all contrasts of stroke or shadow were perceptible. However if the decoration were not perceptible (e.g., lacking time, magnification, or contrast), it would be more likely that the component would not be perceived as interactable.
Details
Perceived interactability of components
Interactability
Note: Interactability was defined as satisfying two criteria:
22
Outer Attributes (context)
Multiple attributes are related to identifiability and perceived interactability!
Component styling (e.g., shadows and outlines) may not have been recommended to identify controls like buttons and chips, but that styling helps – along with a number of additional attributes.
It is the combination of these attributes that aid identification and perceived interactability.
Details
Attributes impacting perception
Attributes
Inner Attributes (component)
Details
Attributes impacting perception
Attributes
Given the combination of these attributes and the context of use, exclusive focus on shadow or outline contrast may be unnecessary
For instance - the image at right shows an example of our mobile button mock, with no shadows or outlines.
One participant suggested that she “didn’t care as much about the border on this one.” Stating, “[I’m] clearly being asked about a task - it’s a confined space, I don’t have to search a whole screen. Also, the fact they’re blue, triggered me that they were buttons or links.”
Clearly suggested here are three additional attributes to consider for identifiability and interactability – namely, font color, display space, and expectation given context.
Details
Consider the user
Consider the User
Vision isn’t always stable – participants stated that their vision changed throughout the day:
“My vision fluctuates throughout the day, based on my glaucoma and on my eye conditions, referred to as retinopathy prematurity - my eyes tire. So I’ll start at the beginning of the day on a 27” display at about 200% magnification. By the end of the day, I’m exclusively using speech at about 600 words per minute, with magnification at about 600%, just to do spot checking” –– P13
The AT they use also may change throughout the day, based on need, on context, on intent, or convenience:
“I’m visually impaired myself, I’ve used assistive technology for most of my life. And, I’m kind of a rare bird, in that I, like, really interchangeably use both reading technology and magnification technology, and braille. All three of those things I’m very comfortable with.” –– P14
25
Details
Consider the user
Once again, on being scrappy – If we don’t provide a way to do a thing easily, our users will find a way (they may not even complain, so we may not even know about it):
“Every day, I mean you run into something. But again, I’ve been playing this game for so many years, it’s like okay, if it won’t work this way, we’ll do it another way!” –– P12
Observation: In general, we observed a willingness to experiment that was, at least in part, due to the relaxing of expectation that things would go right the first time. And again, this willingness to experiment was frequently expressed without complaint – so it’s possible we won’t know how badly our designs work unless we’re listening (e.g., not in logs, not in bugs).
Recommendation: Design for more interrogative or discoverable interfaces; ensure fault tolerance and recoverability is built in from the beginning (trial by error by default)
Consider the User
26
Details
“User” == User + AT
Consider the AT
How our users interact with AT may not be predictable to us – multiple solutions are adopted given need:
“One thing I would say is that - when I invert it, which I really need to do, to be able to actually see things - because the border is really a shadow on these buttons… I don’t know, it inverts a little weird.” –– P14
AT is a part of our users’ lives, in both online and offline contexts:
Multiple participants stated they use a portable magnifying glass for their daily interactions (picture at right), in combination with their digital AT
For the broad spectrum of how users view our design given their vision, there is an equally broad spectrum of how they will use AT within their day (with the same participants varying broadly, individually, every day)
Lighter weight AT use may involve situational awareness, subtle guidance, progressing to validation, to lightweight assistance, to the sole means of consumption.
Portable magnifier, commonly used in combination with AT
27
Details
Consider contrast + state
State
When shown variations of our outlined mobile buttons in light mode, participants suggested there may be state confusion:
“The one on the right [standard contrast], and sometimes when you push a box, for [me], when it’s activating to send, it gets lighter. So it would be harder for [me] to tell what’s going on with what’s going on… If it’s light, it means you pushed it. And if it doesn’t go light, it means you didn’t push it, right? So if it’s light, don’t know if you would see the contrasting change enough to know you pushed it.” — P05
Participant preferred high contrast, followed by none, followed by standard, due to standard looking disabled:
“Because the style of text on [no border], the way the text stands up and pops. As opposed to, [standard] has a thin light border, which to his brain makes it appear greyed out, like he couldn’t click it.” — P16
28
Details
Consider contrast + touch targets
When imperceptible outlines, would need to hit controls in the right spot:
“I would need to click the ‘Yes,’ ‘No,’ or ‘Maybe,’ directly in the word itself (which can be difficult).” — P17
“With the darker borders, it would be easier to make sure you click in the right spot… In essence, I wouldn’t aim to hit anywhere on the ‘Yes’ icon, I would aim for the text - Harder to know where it begins and ends.” — P16
Even with perceptible outlines, still concern around control spacing:
“I would space the ‘Yes,’ ‘No,’ ‘Maybe’ buttons farther apart – because if you’re navigating by touch, you’re very likely to hit the next button.” — P08
Although that concern wasn’t shared by all participants:
“Otherwise, works well, cause there’s enough spacing between them, so you can hit the one that you’re aiming for” — P03
Touch targets
29
Details
Consider attributes + the FAB
FAB
Multiple participants commented positively about the GM primary FAB:
“I like the boldness of the plus [GM FAB]. Despite not having very obvious borders. [What is bold about it?] Don’t know – for being on a white background, it’s usually drowned out… But it seems to stand out more than other standard, black on white [Attr: elevation, color]” — P07
“Likes the [reply FAB], because it looks like it’s on top of the screen [Attr: elevation]” –– P09
“Can see the [dark mode, reply FAB] -- Likes that, “it’s easy to use, easy to see, and quite beautiful, and I like that [Attr: usability, beauty]” –– P16
Though it was identifiable, not always perceived as interactable, in part due to uncertainty of context (plus, bonus call for extended GM FAB)
30
With imperceptible outlines, would need to hit controls in the right spot:
For the Light - Mobile - Buttons - Stroke mocks (right, top), the text looks brighter in the [None] condition than [Standard] — P13, 1/10
For the Light - Desktop - Chips - Stroke mocks (right, bottom), the text looks a bit more grey in the [Standard] condition. Prefers the font on the [None] condition, suggesting it looks thicker than the [Standard] condition. –– P16, 1/16
In both examples above, the [Standard] stroke outline led to the perception that the font was dimmer or lighter weight.
Details
Idiosyncrasies of perception
Tricks & Traps
Another way of looking at the prior slide, side by side. Again, participants suggested that:
Do you agree? Look at the text between the examples at right, then look at the animation at the bottom to confirm that the text is the same.
Details
Idiosyncrasies of perception
Tricks & Traps
Details
Idiosyncrasies of perception
Tricks & Traps
On general preference of dark mode versus light mode:
One participant suggested that a reason for the preference for dark mode versus light was related to* halation, or the perception that objects take on the color of surrounding objects. For dark text on light backgrounds, this may make the white blend into the dark text, decreasing perceived contrast and increasing eye strain.
This blending can be more clearly seen in the example at right, showing equal steps between two colors. The bottom example, in particular, clearly shows the perceived gradient that occurs (each of the rectangles is actually a solid color). Go ahead and copy one of the blocks to an empty slide to check.
(Hit <Cmd> + <Ctrl> + <Shift> + 4 to select an area to copy)
Details
This slide intentionally left (mostly) blank
34
Details
Buttons vs Links - A brief sidebar
Buttons != Links
Participants suggested that controls in the [None] condition (with no stroke outline, no shadow) may be Links rather than Chips or Buttons
While the perception of Links did not generally impact the identifiability or distinguishability of the controls (i.e., participants knew there were three distinct controls, issues with Touch Targets notwithstanding – slide 20), user perception of interacting with a Link is slightly different than a Button. Namely:
The differences are subtle, but the misalignment of user perception if they perceive Links rather than Buttons can cause confusion, lead to friction, and impact the immediate identifiability of the controls.
Details
Preference vs. “pop” – Comparisons in a nutshell
In general, participants preferred the visual design of dark mode, but most also acknowledged that light mode was more identifiable - it “popped” more:
“[Preference between light or dark mock?] Totally [the dark one] -- The contrast of light text on a dark background - always has been my favorite way to view content on a screen.
“[ And which ‘pops’ more? ] Strangely enough, [light mock] in this case. Maybe because the shadows are a bit more pronounced” –– P16
“For me, personally, dark mode [#2] would be the way to go. Once I got past the learning curve -- When I’m running on my computer, most of the time running inverse color scheme, so that would be the way to go. In general, prefer white text, dark background.
“[ And which ‘pops’ more? ] [Light mock], because he can see the box around each choice. On [dark] -- kind of thought there was something around it - but can’t pick it up that well.” –– P12
Comparisons
36
Details
Preference vs. “pop”
Comparisons
Dark mode is preferred, Light mode “pops”
The graph at right shows the tradeoff between preference with regard to visual design, and the perception that a button or chip is identifiable - it’s “pop”
Observation: The majority of participants preferred the visual design of a dark theme even though that preference was at the expense of perceived usability
Recommendation: Recognize that trade-off and account for it in your justification for design. Acknowledgement precludes avoidance – don’t optimize for either usability or preference blindly
37
Details
Preference vs. “pop”
Comparisons
Perceived usability issues (the lack of “pop”) more prevalent for Dark Shadow
The problem highlighted here: the version of dark-shadow in these mocks is less identifiable, less “pop” compared to the light mocks, even if the same participants acknowledge they prefer the dark mode overall
38
Details
Preference vs. “pop”
Comparisons
Perceived usability issues are ameliorated by Dark Stroke condition, compared to Dark Shadow
Note that in this case dark was still preferred, but was now also voted to “pop” more - as in it was “more identifiable, more distinguishable as a possible action”
39
Details
Preference vs. “pop”
Comparisons
Light Shadow vs Light Stroke
In general, users preferred Light Shadow to Light Stroke with regard to visual design. For “pop”, differences were less dramatic
“Oh yeah, the second style looks way better [Light Shadow]. The border is darker - so it looks like I could find the buttons a lot faster. In the previous one [Light Stroke], the border was softer in tone, a lot more greyish than this one [Note: both were high contrast]” –– P10
Dark Shadow vs Dark Stroke
Note the strong votes for preference and pop for stroke. Given comments, one of the main reasons for the discrepancy is the lack of contrast between shadow and background color in dark mode
“Prefers the outline of the buttons [Dark Stroke] -- the borders on [Dark Shadow] are very dark – The borders need to be lightened up a bit.
“The shadow is not the problem, the black on black is the problem” –– P17
40
Details
Preference vs. “pop”
Comparisons
Users, in general, did not prefer controls with no Shadow or Outline
Users preferred the [Standard] or [High] contrast stroke or outline more than the [None] condition for both visual design and “pop”. Preference between [Standard] and [High] was less dramatic.
Note that these values are across Dark and Light, across Chips and Buttons, etc.
41
Details
Preference vs. “pop”
Most “Preferred” across color, component, contrast, and style
Note, small sample size. Not significant, but illustrative
Comparisons
42
Details
Preference vs. “pop”
Comparisons
Most “Pop” across color, component, contrast, and style
Note, small sample size. Not significant, but illustrative