Understanding non-text contrast needs to allow for visible alternative text

[DavidMacDonald]

• We need an explanation that a tooltip visible on hover/focus that contains alt text would be sufficient
• We need an explanation that a graph with a table below it implemented with or without show/hide will be sufficient.

The text would need to be discoverable or visible without assistive technology. It could show up on hover/focus or activation (as in a show hide button). The reason they pass is because with these alternatives the graphic is no longer necessary to understand the content and therefore the requirement does not kick in.

These two examples are important and Alex Li of Microsoft wants to ensure these are in. I support this, and on the call the consensus appears that it is unanimous.

[mraccess77]

I don't consider this an editorial change.

The SC states "when a particular presentation of graphics is essential"

The proposal seems to go beyond what is written and say if there is a visual alternative then this SC would not apply for graphics. While this is an improvement it very much limits the effect that this SC will have on complex graphics. More broadly a requirement for a visual alternative might actually provide more users benefits.

The issue is not whether the graphic is essential but whether the particular way it was presented is essential. Those are two different things. It's frustrated to see this gutted at the last minute.

[alastc]

There are two "caveats" for the graphics contrast, one is esential due to the way it must be presented, the other is 'required for understanding'.

Since last year (or at least Jan this year) the Understanding doc has included:

Required for understanding

The term "required for understanding" is used in the Success Criterion as many graphics do not need to meet the contrast requirements. If a person needs to perceive a graphic, or part of a graphic (a graphical object) in order to understand the content it should have sufficient contrast. However, that is not a requirement when:

• A graphic with text embedded or overlayed conveys the same information, such as labels and values on charts.
• The graphic is for aesthetic purposes that does not require the user to see or understand it to understand the content or use the functionality.
• The information is available in another form.
• The graphic is part of a logo or brand name (which is considered 'essential' to it's presentation).

And just under that:

Dynamic Examples

Some graphics may have interactions that either vary the contrast, or display the information as text when you mouseover/tap/focus each graphical object. In order for someone to discern the graphics exist at all, there must be contrasting colors or text in order to find the graphics. Within that area, information available by a conforming method (e.g. focusable elements) can be used to make that information available dynamically as text, or dynamically increase the contrast.

I'd been expecting some comments on those, I guess this sort of is comments on wishing those were there, when in fact they have been...

[alastc]

Oh, and @DavidMacDonald, please be careful with using the term 'alt text' here, that implies that if the thing has an accname it passes, that is not the intent.

[mraccess77]

@alastc I saw that in the understanding document -- but the understanding documents aren't normative and that reads different from the SC. WCAG has always allowed alternatives -- but the functionality test for those is sometimes not as clear. For example, a text transcript version of multimedia doesn't pass as an alternative to audio description 1.2.5 because the content even though including all information and visuals is as text and not video. I

[mbgower]

I think we need to be very mindful of the dual role of the SC, which independently cover

1. sufficient contrast for the outer edge of components (and indications of state), and
2. sufficient contrast between meaningful parts of graphics.

For controls, both roles can apply. A user must be able to distinguish the outer edge of a control via sufficient contrast to be able to discern it. If it lacks that contrast, it should fail regardless of any text label on the graphic or any TITLE value that appears on hover. But if the outer edge passes, then a (keyboard accessible) TITLE attribute that supplied a text alternative would arguably allow the control to pass the second SC role -- the text clarifies the shape's role, so it is no longer necessary for the user to discern the contrast of different shapes within the object to figure out its purpose (the contrast within the object is no longer essential).

For a graph that is not an operable component, one could use a legend to properly label the portions of a graph, but if the portions are not discernable from one another due to poor contrast, then it would still fail. The contrast remains essential to distinguish the graph, regardless of 'text alternative'.

[alastc]

Hi @mraccess77,

the understanding documents aren't normative and that reads different from the SC.

The bits I quoted above are clarifying 'required for understanding', I don't see how are they different? If that part of the SC were expanded to include aspects on those I'm not sure where it would stop, it would become a huge SC. (Plus it's too late for that.)

For example, a text transcript version of multimedia doesn't pass as an alternative to audio description 1.2.5 because the content even though including all information and visuals is as text and not video.

There's no equivalent scoping for 1.2.5.

@mbgower wrote:

one could use a legend to properly label the portions of a graph, but if the portions are not discernable from one another due to poor contrast, then it would still fail. The contrast remains essential to distinguish the graph, regardless of 'text alternative'.

Indeed, but to be fair if the graph included (contrasting) text values for the sizes of bars in the graph, that would pass, as per the pie chart examples that have been in the understanding doc from the 1st version.

The worry I had about the dynamic example was that it leaves a hole - if you can't discern it in the first place you wouldn't know that it was there to start with.

However, @mbgower makes a good point, if it is dynamic (interactive) then it is also a UI component, so the component as a whole needs contrast, and the 'content' within it can have contrast selectively (e.g. on focus/hover). So with an outer border, I think this would be a good example.

[mbgower]

Indeed, but to be fair if the graph included (contrasting) text values for the sizes of bars in the graph, that would pass, as per the pie chart examples that have been in the understanding doc from the 1st version.

Agreed

So with an outer border, I think this would be a good example.

That is a pretty cool implementation! I love how one can move around the pie segments by arrow and have the matching segments highlighted in sync on the other pie charts. I love how when navigating around the legend, the associated pieces of the pie are highlighted.

There is at least one thing I would object to as a 'good' example for this SC, and a very points to ponder:

• Yellow "Meeting" segments do not meet 3:1 contrast with white background (easy to fix)
• the hover effect (and arrow navigation) on any segment renders the rest of the pie into low-contrast. See the following points for further discussion, but to me they could reduce the contrast difference when things aren't focused to achieve the same effect while also making the other segments still meet contrast. After all, the other segments aren't disabled. Actually, the easiest thing to do would be to leave the outline full strength and reduce the internal portion, which is I think what you were saying.
• These visual changes occur through user interaction. Before I interact I can detect the whole pie and (once the yellow is fixed) each of the segments. So half the job is done. But it seems to me they've altered the state to indicate hover/focus, (bullet one of the SC) but the interaction raises the question about if the other parts of the graph are required once I choose to interact (bullet two of the SC). Does it matter as much if the contrast on the parts I'm not interacting with is lower? I think in this case, it should.
• Another question this raised: is the pie a user interface component? On the one hand, I can navigate/control the parts via keyboard AND cause alterations in the graph by hover. On the other hand, there is nothing to "activate". Clicking or pressing enter does not intiate anything.
  I don't think this meets the definition of a UI component, but it does make me realize that as we encourage more interactive graphs, etc., the line between what is a control and what is a navigable read-only graphical object may become blurred.

An aside, there is some flakiness in the tab navigation between the pies. My expectation would be, having brought the Meeting segments into prominence via my input control (i.e., arrowing around a pie), I would then move between the same highlighted segment on each pie when I tab. Instead, I move to the 'top' segment on the next pie.

[WayneEDick]

Hi All, I'm putting my mathematician hat on for this. Most graphs are unambiguous representations of mathematical relations. Take a pie chart. It is a pictorial representation of a statistical distribution. It is a mapping from a set of subpopulations into percentages that add up to 100%. You can represent that relation in many ways: a table, a list etc., but the pie chart is really perfect for certain presentations. Generally the author's graphical choice for representing a particular relation is to emphasize some meaningful aspect of the relation. The intent of this SC should be to make the author's graphical presentation of choice visible to users with impaired contrast sensitivity. The goal is to see exactly what the author illustrates. If a text alternative would have worked as well to present the concept the author would probably use text because it's easier. Let's return to the pie chart. In the US Discretionary Budget is dominated by Defense. But a pie chart makes the point dramatically. Steven Hawkings liked to point out that motion being relative, the model of the sun going around the earth is just as accurate as the earth going around the sun. The latter just makes computation of planetary motion usable. How the author chooses to present mathematical relations is part of the meaning. Wayne

…

On Fri, Apr 13, 2018 at 11:54 AM, Mike Gower ***@***.***> wrote: Indeed, but to be fair if the graph included (contrasting) text values for the sizes of bars in the graph, that would pass, as per the pie chart examples that have been in the understanding doc from the 1st version. Agreed So with an outer border, I think this would be a good example. That is a pretty cool implementation! I love how one can move around the pie segments by arrow and have the matching segments highlighted in sync on the other pie charts. I love how when navigating around the legend, the associated pieces of the pie are highlighted. There is at least one thing I would object to as a 'good' example for this SC, and a very points to ponder: - *Yellow "Meeting" segments do not meet 3:1 contrast with white background* (easy to fix) - the hover effect (and arrow navigation) on any segment renders the rest of the pie into low-contrast. See the following points for further discussion, but to me they could reduce the contrast difference when things aren't focused to achieve the same effect while also making the other segments still meet contrast. After all, the other segments aren't disabled. Actually, the easiest thing to do would be to leave the outline full strength and reduce the internal portion. - These visual changes occur through user interaction. Before I interact I can detect the whole pie and (once the yellow is fixed) each of the segments. So half the job is done. But it seems to me they've altered the state to indicate hover/focus, (bullet one of the SC) but the interaction raises the question about if the other parts of the graph are required once I choose to interact (bullet two of the SC). Does it matter as much if the contrast on the parts I'm not interacting with is lower? I think in this case, it should. - Another question this raised: is the pie a user interface component? On the one hand, I can navigate/control the parts via keyboard AND cause alterations in the graph by hover. On the other hand, there is nothing to "activate". Clicking or pressing enter does not intiate anything. I don't think this meets the definition of a UI component, but it does make me realize that as we encourage more interactive graphs, etc., the line between what is a control and what is a navigable read-only graphical object may become blurred. An aside, there is some flakiness in the tab navigation between the pies. My expectation would be, having brought the Meeting segments into prominence via my input control (i.e., arrowing around a pie, I would then move between the highlighted segment when I tab. Instead, I move to the 'top' segment. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#861 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OFx83GzQA2yxJeOcAF7iwpk5QnFUQks5toPRxgaJpZM4TOjZO> .

[lauracarlson]

@WayneEDick makes a good point.

Designers create data visualizations because it makes data easier to understand. Some analysis is typically required to make a chart or graph.

Joe Clark talked about this in a 2006 WCAG comment. He said:

We create diagrams because data are too hard to understand. To use an analogy over again, diagrams and data are like a suitcase that can be unpacked but not easily repacked. If data were understandable by themselves, We wouldn't make a chart. I can assure the Working Group that giving nondisabled people a really nice chart and disabled people a table with 10,000 or more data points does not constitute equality in any sense.

[alastc]

Designers create data visualizations because it makes data easier to understand. Some analysis is typically required to make a chart or graph.

Certainly, and there are many ways to to do it, only some of which could have sufficient contrast.

As soon as you get to a certain number of colours (3 or 4 at 3:1) that make significant contact, you cannot have sufficient contrast.

Using the 'required for understanding' as a scoping mechanism (including allowing for visible text fulfilling the same information) gets over significant objections about feasibility, without which I don't think we'd have this SC.

For @mbgower's detailed comments:

Yellow "Meeting" segments do not meet 3:1 contrast with white background (easy to fix)

The green to.

For the purpose of this, let's assume it does not show the number values by default.

the hover effect (and arrow navigation) on any segment renders the rest of the pie into low-contrast.

Does it matter? Assuming they are visible by default, putting the focus on one (and showing the values) seems like a reasonable thing to do, does it matter that the others fade out? They become difficult to see for everyone! And you can move between them.

To make a more extreme argument, if the graph as a whole is perceivable, and the hover/focus shows the values (and perhaps increased the contrast or added a border), do the slices need to meet contrast?

In this case I'd say yes, but only so that it is perceivable in the first place.

An aside, there is some flakiness in the tab navigation between the pies.

It was ok for me, at least in FF. Tab between pies, arrow between slices. Goes a bit funky if you mouse pointer is also above a slices. The individual pie chart is probably a simpler (complex) example.

[DavidMacDonald]

Given that the line "The information is available in another form" is in the Understanding, which echos the SC text "Parts of graphics required to understand the content, ...", the issue appears to be covered in the understanding although not as explicitly as this issue proposes. Maybe that is a good thing. Its there but we're not promoting that authors avoid contrast when they have an alternative way to get the content.
Therefore, I'll close the issue.

[mraccess77]

@DavidMacDonald wrote "to understand the content with AT "

What if you are not using AT? Many people with low vision might just be using zoom or other browser features. Any information would have to be visible on the page and not just available to AT. In addition, the original intent of that clauses and the intent of the low vision working group was that only the parts of the "graphic" required for understanding the "graphic" had to have sufficient contrast not taking into account other page content. It was meant to exempt parts of graphics -- not the whole graphic.

A graphic is not the same as a table and many of us or visual learners and want graphics to be accessible and don't want to have to use a data table which is much more difficult to understand and interpret. This is among other things that the LV task force did not get into the WCAG 2.1 guidelines is why I had proposed that language be added to the introduction indicating that the needs of users with low vision were not fully addressed and more work needs to be done.

I agree with Lisa that having graphics with sufficient contrast will aid users with cognitive and learning disabilities as well.

[lauracarlson]

@DavidMacDonald wrote: "to understand the content with AT "

@mraccess77 wrote:

What if you are not using AT? Many people with low vision might just be using zoom or other browser features. Any information would have to be visible on the page and not just available to AT.

Yes, Jon is correct. The LVTF's original (September 2016) intent:

The intent of this Success Criterion is to provide enough contrast for icons, form field borders and graphics that convey important information so they can be perceived by people with moderately low vision (who do not use contrast-enhancing assistive technology).

People with low vision often have difficulty perceiving graphics that have insufficient contrast. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a relative luminance (lightness) difference of 3:1 or greater can make these items more distinguishable when the person does not see a full range of colors and does not use assistive technology.

That was diluted to what we have now. Can we try to keep the SC meaningful to people with low vision who do not use AT.

[alastc]

I think there is some confusion here, the Understanding doc says without AT, and I don't think David is proposing otherwise, he said:

The text would need to be discoverable or visible without assistive technology.

[lauracarlson]

Hi @alastc ,

I think there is some confusion here, the Understanding doc says without AT, and I don't think David is proposing otherwise.

That's great. Had me a bit worried. Thank you for the clarification!

[mraccess77]

My comment had been from an email from github prior to David editing his comment to what it states now.