Minimum requirements for "Conforming Alternative Versions" #2720
Comments
|
I think this is an important question - and hard to answer for the examples you gave. I think it's easier to answer for a diagram:
Regardless of the outcome of the discussion, I support the intention that it should be more precisely determined and documented what the minimum requirements for "Conforming Alternative Versions" are |
Sorry for the thread drift over there, (and promise I won't here) it was intended to paint a picture of why and how 1.4.1 is misinterpreted, and also why a table of values is a poor "alternate" in many if not most cases. If you take a glance at science literature, complicated graphs are commonly printed in black and white. Tables, when used, are for when data does not graph well and a table is a better display of the data. Tables are usually not a good alternate when a graph is illustrative of the data presentation. There is an old phrase in design for print: "Make it right in black and white"For hundreds of years, printing was primarily black and white, or half-toned greyscale, with a single black ink. It really wasn't until the late 70s/early 80s that economical color printing became more common (and today with digital pre-press, more the norm). But a point is: even if printing in color, designers have been admonished to make the design "work as a black and white"—even if a main item would be printed in color, it was very common to also print a black and white only version. I feel that a lot of the classical wisdom for print has been losgt in recent decades, and that is unfortunate. But there is no reason that the same considerations can not be applied to web, and they arguably should be. Thank you for reading, Andy |
|
+1 to a table is not a substitute or equivalent for a chart or diagram
- for people who are blind - it may be the only alternative available - but like ALT text — it is no substitute for the picture unless you have no vision and need to work with a text description. EVEN THEN - it would be good for there to be text explaining the trends or other things that are visibly obvious but will not be obvious in a table.
+1 again for "Make it right in black and white" or (I think better but does not rhyme) "Make it work in black and white"
- that does not mean - the chart needs to be in black and white. Color is marvelous and should always be used where possible. But COLOR alone should not be used in the diagram. It should ALSO work in black and white.
Best
g
Gregg Vanderheiden
***@***.***
… On Oct 10, 2022, at 4:05 PM, Andrew Somers ***@***.***> wrote:
Hi @detlevhfischer <https://github.com/detlevhfischer>
taken off on another tangent (in-depth discussions of color),
Sorry for the thread drift over there, (and promise I won't here) it was intended to paint a picture of why and how 1.4.1 is misinterpreted, and also why a table of values is a poor "alternate" in many if not most cases.
If you take a glance at science literature, complicated graphs are commonly printed in black and white. Tables, when used, are for when data does not graph well and a table is a better display of the data.
Tables are usually not a good alternate when a graph is illustrative of the data presentation.
There is an old phrase in design for print: "Make it right in black and white"
For hundreds of years, printing was primarily black and white, or half-toned greyscale, with a single black ink. It really wasn't until the late 70s/early 80s that economical color printing became more common (and today with digital pre-press, more the norm).
But a point is: even if printing in color, designers have been admonished to make the design "work as a black and white"—even if a main item would be printed in color, it was very common to also print a black and white only version.
I feel that a lot of the classical wisdom for print has been losgt in recent decades, and that is unfortunate. But there is no reason that the same considerations can not be applied to web, and they arguably should be.
Thank you for reading,
Andy
—
Reply to this email directly, view it on GitHub <#2720 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQPH3A3V5M45LK5KM3WCSOKHANCNFSM6AAAAAARBIQUHE>.
You are receiving this because you are subscribed to this thread.
|
while for print it may well be true that we need to consider pure monochromatic black/white (since that's the only actual ink color you have, and even grays are only possible with halftone patterns / dithering), for digital we're obviously not just restricted to pure black and pure white. make it work in grayscale may be more appropriate as a guiding principle. |
|
But greyscale doesn't rhyme... 😎 The adage "make it right in black and white" means greyscale, just as a black and white television is a greyscale television and black and white film was a very wide latitude greyscale emulsion. Tangent Ramble:I suppose it may be my age showing here, but colloquially when we'd say B&W we always meant the full greyscale from black TO white, not a binary black OR white — black AND white means the full-range. It just occurred to me reading your post that no-one today uses black and white TVs nor black and white film stock....!! But I can tell you that in the 1960s & 1970s, color in printing and television was a luxury and "B&W" was common (UPHILL BOTH WAYS!) Today of course, none of this may make sense: B&W displays are unheard of, B&W film more or less vanished as color film vanished, B&W printing is "available" for low end products like paperback books, but with digital prepress and digital-to-plate automated 4 plate offset presses, printing a book in full color is not "that much" more expensive than printing with a single plate press. And all offset printing, B&W or CMYK color, uses half-tones. With an 8-plate press, you have 4 plates for CMYK then some additional spot colors, i.e. Pantone for brand colors, or lacquers for printed gloss or other special effects, but that's for very high end work such as corporate annual reports or automotive sales booklets, but color or BW, all gradients and color mixing in print is through the use of screens (halftones) with a dpi of 300 on coated paper for high quality work, the "dots" aren't visible without magnification. |
Hi @GreggVan, Maureen Stone authored a good, brief guide for NIST on this subject: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=900104 |
|
@detlevhfischer is it your strong preference for this thread to be limited to charts and graphs and the like?
It might be safe for this thread, but the conformance requirement does need to include functionality IMHO. One common example is a keyboard accessible date picker where an end-user has the option to enter a value. The visually-oriented mouse user gets a little more information, since the tabular presentation implicitly provides the day-of-the-week because that is the convention with tables that have exactly seven columns. The consensus position in AGWG is that this such an approach is tolerable. With a date-picker, the CAV might be on the same page. A web page with an image of a chart, descriptive identification as |
|
Black and white does include (a) grey but not more that one I think - and it should be midway.
- that would still be visually obvious but more would
Patterns are much better.
So does that make it "Make it right in black and white and 1 grey?" (Grin)
… On Oct 11, 2022, at 2:05 AM, Patrick H. Lauke ***@***.***> wrote:
+1 again for "Make it right in black and white" or (I think better but does not rhyme) "Make it work in black and white"
that does not mean - the chart needs to be in black and white. Color is marvelous and should always be used where
possible. But COLOR alone should not be used in the diagram. It should ALSO work in black and white.
while for print it may well be true that we need to consider pure monochromatic black/white (since that's the only actual ink color you have, and even grays are only possible with halftone patterns / dithering), for digital we're obviously not just restricted to pure black and pure white. make it work in grayscale may be more appropriate as a guiding principle.
—
Reply to this email directly, view it on GitHub <#2720 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXS7JJIZBUH6EEOJZDDWCUUWXANCNFSM6AAAAAARBIQUHE>.
You are receiving this because you commented.
|
|
Hi @GreggVan
I think I am misunderstood. In a design and display sense, "B&W" means greyscale. But in an information coding sense, then no, and here I agree — if we are coding things wherein the coding is using the luminance of the grey and intended to have a specific meaning. Some FAA standards limit coding using achromatic (greys) or a set of monochromatic, to three levels, B/G/W — and in the case where there is no "comparison to" then three levels being black grey white is appropriate, especially for a control or indicator that is in isolation to other values. On the other hand, where there is a coding of a series graduated values in adjacent or close proximity, where there is "immediate comparison" then the number of grey values for coding can in theory be increased. Common cases would be data on a map or in a pie chart. On the subject of pie charts, due to the nature of spatial frequency effects on discrimination of color, large pie pieces can use more color (hue/chroma) contrast, but small thin slices need significant luminance contrast for good discrimination, as color discrimination drops rapidly at higher spatial frequencies. |
|
+1 to this
This is an excellent way to say what I was trying to say
gregg
… On Oct 11, 2022, at 1:22 PM, Andrew Somers ***@***.***> wrote:
I think I am misunderstood. In a design and display sense, "B&W" means greyscale.
But in an information coding sense, then no, and here I agree — if we are coding things wherein the coding is using the luminance of the grey and intended to have a specific meaning.
Some FAA standards limit coding using achromatic (greys) or a set of monochromatic, to three levels, B/G/W — and in the case where there is no "comparison to" then three levels being black grey white is appropriate, especially for a control or indicator that is in isolation to other values.
|
This thread is not about discussions of color, greyscale, black & white etc. Instead, it focuses on the general requirements for (the use of) confoming alternate versions (CAV) if these are used by authors to claim conformance, and by the same token, on the question whether a CAV can be accepted at all in situations where content can be made accessible for some users (say, color-blind people) without using a CAV - even when a CAV is provided to accommodate other user needs (say, by supplying a data table for blind users). A chart with a table alternative is just one case. One question is whether "same information" is not just in the data points but extends to relations between data points. The argument seems to be that a trend visually rendered in the comparison of heights of bars in a bar chart, for example, must have some corresponding explanation in any conforming alternative version, e.g., by supplying additional text (which in addition to the data points in a well-structured data table might say something like "turnover has doubled from 2021 to 2022"). If this argument is made, then we are opening a can of worms of subjective judgments as to exactly what traits of a graphic need to be rendered in explanatory text in addition to providing the same information in another format (in the sense that an excel sheet can be converted to different graphical outputs and all these are equivalent to the sheet from a data perspective). By the same token, it seems to me not sufficiently clear from the definition of "Conforming Alternate Version" that such a version can only be accepted as conforming if suitable means of improving the accessibility of the primary version for specific user needs (say, color-blindness) have been exhausted: for example, by using not only color, but also a second graphical indication such as pattern to convey the information. I get the feeling the thrust of my argument has not yet really been appreciated here. I would like people to abstain from discussions of color discirimation etc. since this is orthogonal to the point I am trying to make. |
|
It did seem to me that the several comments related to color were off topic. I am pretty confident that I have had my share of CAV related questions. Tolerance for CAV is something that I have made peace with. I agree that "provides all of the same information and functionality'" is more subjective than most other aspects of WCAG. Do you have a specific suggestion for improving the normative or informative text? Above, I wrote that I disagreed with your assertion that, in general, "it is safe to concentrate on 'information' rather than 'functionality'" but you might have meant charts specifically and not as stand-in for the general principle. On this point, I do not have clarity. The reason I would generally regard a link to spreadsheet as a CAV to a chart is because spreadsheets are as close as we humans have come to providing a text equivalent to charts. I mean, the chart was probably generated from a spreadsheet which itself is a subset of a much larger data set. On the other hand, it would not be hard to find charts and corresponding 2D data table which are not, in actuality, anything close to an equivalent because the meaning is so buried in the numbers that they might as well be random noise. I would push back on page owner who asserted tabular data as being the CAV provided to meet a requirement for good contrast. A perspective I would offer on CAV is that they are not usually an accommodation to a particular disability. Having a specialized version of content in deference to accommodating some population is a justification for allowing use of CAV (when the specialized version does not conform to WCAG) but that is rare is my experience. The CAV is usually for content where the author does not know how to meet one or more Success Criteria, and the CAV is and used for the purposes of conforming to WCAG and allowing the non-conforming version to be excluded from the scope of an audit. In these cases, the content under review still needs to meet all of WCAG, not just the SC which tripped up the "primary" non-conforming version. If your web page includes links to color-blind friendly versions of your charts, that can be an acceptable way to meet SC 1.4.11 Non-text Contrast. The page still needs to meet SC 1.1.1 Non-text Content and other applicable SC. I don't think this example of extra hi-contrast charts is a good example of CAV because, as you note, more patterns and fewer color would a much better approach. It is also probably less work for the page owner! FWIW, I do not usually find it productive to frame the non-conforming version as the "primary" version and in my experience, that is a red flag that the CAV needs to be assessed carefully. In actual practice, an image-only PDF linked from an accessible web page of the same content is not much of barrier, and can pretty easily meet the four enumerated literal requirements of the CAV definition. I think an analog with charts and the like is a similar situation. |
If a CAV exists for a process then that process would need an equivalent in the CAV, of course. I was just concentrating on the simple bar chart with table CAV as an example where process would not be relevant. @bruce-usab If I get your gist, this might be formulated as this phrase: It might be helpful to run through a typical example of a (more complex) in-page CAV: An map embedded on a page shows the service points of some parcel service provider as icons. Activating the icons calls up popups with the respective adresses. A tabular view below that map lists all the same locations/adresses alphabetically, offering a CAV for (primarily) blind users who can in this view search for, or sort, service points in their postcode area. Now, for sighted keyboard users, there is added value in accessing the dots on the map so you can identify the location closest to your home to get its address, for example, to copy it as the desired shipping address - something much harder to glean from a table view. Therefore, the argument would go, all the icons need to be keyboard-accessible with proper focus handling, its popups with proper dialog mark-up etc. Put more generally, the mere presence of a CAV does not absolve the author from ensuring that all SCs that are possible to meet on the primary version are met there: full keyborad accessibility, contrast, focus visibility, 1.4.1 color, semantic markup, etc. etc. This would then not just be "best practice", but normatively required. For the map example, it would follow that the existence of an accessible table of service points does not mean that the map can be disregarded as non-conforming version because it contains visual information (like proximities / distances) that are important for all sighted users. Any deficiency that authors can conceivably remedy on the primary element (the map) must be remedied there (or else content fails), in addition to providing a fully accessible in-page CAV where needed for some user group. It this is WG consensus, it sets the bar significantly higher than where we have usually set it in our audits (where we would, for example, accept content where icons on the map are not keyboard-accessible if a data table with the same service point details exists below the map, as an in-page CAV). The bar is set even higher considering that much content (like maps) comes from third parties and may be hard or impossible to edit - so useful content (such as maps) might be avoided because in cannot be made as conformant as theoretically possible. I am aware that the fourth Note in the CAV definition says "Each version should be as conformant as possible" - but that is a SHOULD, not a MUST. So, is this the WG consensus? |
|
If we look at Figure 20 in https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html, we get the impression that according to WCAG it is sufficient to provide a text alternative for graphical content, even if for visually impaired people the graphic could be designed in such a way that the text alternative would not be necessary for them:
|
Yes, that note, like everything in TR/WCAG has been closely vetted by AG WG and has consensus.
That strikes me as aspirational because it is too subjective. How would you write a test for "primary"? How would you assess that the author can meet SC? The alternative is to change the must to a should and note as a best practices — which is what Understanding already says. @JAWS-test wrt that Figure 20 and the related prose, please suggest an edit which is less suggestive that it is sufficient to provide text alternative for graphical content instead of graphical content that works for people with low vision. In context, that is not the impression I take from your excerpt, but there is always room for improvement! |
@bruce-usab Sorry for the misunderstanding - this question was not aimed at the note, but at the overall issue explained above.
"Primary" is simply the content for which a CAV stands in to ensure conformity. In my example, primary would be the map, the CAV would be the table underneath. I am still trying to get a sense as to the WG consensus on the acceptability of CAV when the primary/original version has deficiencies that could be remedied there, in the original - as exemplified by the map example. I consider this issue is still open. We (as WG) might be able to do better than saying "it depends" - but perhaps not, in which case it is then always down to subjective judgment what issues some auditor would demand to be remedied in the primary version, and what information aspects may be accepted as lacking in the CAV without it failing to be considered the "same information". |
With the 2.2 related work, there have been only a few 2.0 normative edits accepted by the WG. What you describe, seems to me to be a significant change. But I suppose, there is no real harm with submitting a PR? If you scan through WCAG (and even Understanding), use of the term "primary" is scant. I think that term will be very hard to define in a satisfactory way. An adjective which is frequently used is "non-conforming" but that is not getting at what you want. |
I can only do that if there is a consensus on the subject. But there doesn't seem to be one, or the example reflects the current consensus, which I don't like, but have to accept. |
|
@bruce-usab I had already tried this 3 years ago, but unfortunately without success: #870 |
I believe that to be correct. But that does not preclude more advocacy of best practices in Understanding. |
|
That is not quite correct
The text alternative is OK for access by people who are blind
But the chart STILL has to be designed in a way that does not depend on color alone.
Text is not equivalent to a diagram (something about a picture and 1000 words).
A text alternative is considered sufficient for meeting the minimum accessibility standard for blind people because we don’t know how to do better now. But it is not sufficient for people who are just color blind - where we do have readily achievable methods to make diagrams that use color encoding.
For example - something that has red for hot and green or blue for cool areas on a map can use dark red and light green or blue to show the gradient in hue and lightness.
PS there will always be borderline cases where one cannot figure out how to encode a complex visual in a way that works in black and white. But for charts where color coding is used - it is almost always possible.
All regulations that cite WCAG also have exceptions where it is "not technically possible" or "presents and undue burden" so the edge cases can be handled this way - we do not need to wipe out guidelines because of edge cases.
best
g
… On Oct 19, 2022, at 12:20 AM, JAWS-test ***@***.***> wrote:
If we look at Figure 20 in https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html, we get the impression that according to WCAG it is sufficient to provide a text alternative for graphical content, even if for visually impaired people the graphic could be designed in such a way that the text alternative would not be necessary for them:
Not applicable: The pie chart has visible labels and values that convey equivalent information to the graphical objects (the pie slices).
—
Reply to this email directly, view it on GitHub <#2720 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXUAT25MX4K6RU573RLWD6OM7ANCNFSM6AAAAAARBIQUHE>.
You are receiving this because you were mentioned.
|
As the original issue "Use of Color and graphs with data table" #2690 has taken off on another tangent (in-depth discussions of color), I would like to rephrase the original issue - which revealed disagreements between different members of AGWG - in more general form.
In Conformance Requirement 1, WCAG in principle allows for a "conforming alternative version" of not fully accessible content, which may be an in-page alternative. So I think the point of contention in the original issue (Can a chart that relies the perception of color conform - meet SC 1.4.1 color - if there is a data table version?) is down to the interpretation of the second bullet point of the definition of "conforming alternate version":
I think it is safe to concentrate on "information" rather than "functionality" here, since the chart does not implement a process.
So the question is: What does "same information" mean here? Since different modes of use have quite different ways of accessing and processing data to turn them into information, this boils down to comparing the end result after whatever senses we can bring to bear on the data have processed it. Can each user, with whatever disability, answer a question such as "By how much has turnover risen between 2022 and 2022"?
In the reponses to #2690 it has been pointed out that for visual users, a data table is harder to use than a chart. That is certainly true. But if the Working Group intends to mandate that implementing the "same information" means that authors must avoid a "conforming alternative version" wherever possible (in the original example in #2690, a table will still be needed for non-visual users), or have to stay as close as possible to the not fully accessible version, this is something that should be spelled out in the definition.
In practical contexts, there are many situations where the conforming alternative version does not afford the same ease of use. Here are some examples:
You get the idea and can think of other cases, I guess. (Case 4, the complex line chart, serves to show the context dependency of all such decisions as to "best conforming alternative".) In cases 1-3, alternative versions are considerably less easy to use than the original (for some users). My point is that we can accept them as alternative versions if they retain the relevant information. So I still believe a simple bar chart (semantically, a two-dimensional matrix with discrete data points) can have a data table as a conforming alternative version IF this table meets all WCAG criteria AND has the same discrete information as the chart. Per alternative version, the chart would meet 1.4.1 simply because its alternative, the table, does not rely on the perception of color (I know it is not the best solution, but that isn' t the issue here). That the combination of discrete points of information may afford more overview, better judgment, be easier to use in certain views (so that it is easier to see a trend, for example) is granted, but I think we enter a slippery slope when we are trying to bring in assessments of ease of use per type of disability in our deliberations as to whether something intended as a conforming alternative version can actually qualify as conforming (on a minimum level).
That other versions of some content (best of all, avoiding a conforming alternative version altogether) may be preferable and easier to use seems to me down to best practice recommandations which we should certainly give whenever we can - but should not impact on assessments of minimum conformance.
The text was updated successfully, but these errors were encountered: