Success Criterion 1.4.11: Non-text Contrast (Level AA) #82
Comments
maryjom
changed the title
|
Created survey of 1.4.11 due on 16 February. |
|
Definition of "state" in WCAG 2.2 is:
Since this definition applies as written, it can simply be listed in the Glossary Items that Apply to All Technologies section. |
|
Testers often ask: Without access to application source code, how do I determine whether "the appearance of the component is determined by the [user agent or platform software] and not modified by the author"? To address this question, I propose adding the following note. "Note: An example of appearance modification by the author is an application that sets the visual style of a control, such as a color or border, to differ from the default style for the platform." |
|
Thanks @mitchellevan for pointing out this issue in my issue #94, which now seems redundant. I have no access to the survey linked to above, and wonder whether WCAG2ICT (and probably in turn vor an EN clause 11 update) has now firmly agreed on the position that native controls that do not meet contrast (like the iOS switches) are then to be exempt when used without modifiation in mobile apps. That is my understanding now. @maryjom Is that an agreed position of the WCAG2ICT group? |
|
@detlevhfischer The survey results should be accessible by anyone. The task force is discussing in our meeting today. These SC issues are to introduce draft content to the Task Force, which we in turn discuss after surveying. Today begins the discussion on this topic so your input is quite timely. We will discuss your comments as well during our meeting. |
|
@maryjom Thanks, I can indeed see the results. |
|
Cases to think about:
|
|
Single lightness is one thing exception - but grayscale is materially not as SC 1.4.11 is focused on differences in lightness which can be done in grayscale as well. It's not specific to hues. |
|
Option # 2 for the note (from the Task Force call today):
Option # 3 for the note (plainer language):
|
|
@mitchellevan I like Option 3 - nice and simple. |
|
I have a concern about my phrase "platform defaults," which conveys scenarios # 1 and # 2 in the following list. The normative phrase "appearance determined by the [user agent or platform software]" actually covers three scenarios:
Rather than re-complexifying the language, let's think about adding a second example. Option # 4 for the note (adding an example of appearance not modified):
Combined with the word substitution "user agent or platform software," if agreed by the Task Force this note will confirm @detlevhfischer's assertion:
|
|
The user agent exception was very tightly scoped to "appearance of the component is determined by the user agent and not modified by the author;" So any visual modification by the author would impact this - not just color or focus indicator. If the user has made changes to platform settings that overwrite the styles then that is out of the control of the author. Historically WCAG has not for example, been applied in high contrast mode. |
|
Hi @mraccess77, I agree with your last comment, and as far as I can tell all four proposed Note options are already consistent with your comment. Can you point out something specific that's incorrect or not clear enough in the proposal? |
|
I can't find option 1 - but option 2 seems most accurate with 3 and 4 appearing to imply that other visual styles aren't covered. |
|
I'm thinking some simple options might be: Option 1:
Option 2:
Thinking about my previous comment from a conversation with Sam Ogami regarding closed products or products with specific types of monochromatic LCD or LED screens. We had discussed the two cases:
I think this would be covered by the exception. @mraccess77 I'm not talking about all LCD screens, but there are classes of monochromatic LCD screens where only brightness can be adjusted, not grayscale.
|
|
I agree with @maryjom on points 1 and 2 in her comment. There are devices where that lack control of color. For part 2, I cannot think of non-closed devices in this situation. |
|
We need to separate documents from software from hardware.Our guidelines deal with documents and software — not hardware.Closed products are not covered by our guidelines in many ways — so I don’t think we should spend time / effort etc. on closed product issues. We just need to say that closed products are not covered by WCAG or WCAG2ICT. And then focus back on documents and software. If we are going to dive into closed products here - -then we should in other areas too. But just be aware — that if we open up the closed products area — it will triple our workload - and require is to CREATE new guidelines etc. (which of course is outside of our mandate so I guess we don’t need to worry about this) . On Feb 24, 2023, at 12:14 PM, Mary Jo Mueller ***@***.***> wrote:I'm thinking some simple options might be:Option 1:
Note: Honoring all user agent or platform settings for color and style is an example of appearance not modified by the author.
Option 2:
Note: An example of appearance modification by the author is an application that sets the visual colors to differ from the default style for the user agent or platform.
Thinking about my previous comment from a conversation with Sam Ogami regarding closed products or products with specific types of monochromatic LCD or LED screens. We had discussed the two cases:
When color values cannot be set by the author (e.g. Monochrome LED or LCD screens).
I think this would be covered by the exception. @mraccess77 I'm not talking about all LCD screens, but there are classes of monochromatic LCD screens where only brightness can be adjusted, not grayscale.
Test issues: when color values aren't programmatically available and there is no capability to screen shot to test color.
Testers would have take a picture with some camera which could inadvertently skew colors. The colors may appear differently because of coatings on the glass (privacy, matte finish, etc.) or level of backlighting of the screen that could negatively affect the ability to accurately capture or determine color values and contrast. This is often the case on closed products - no accessibility layer or API to query colors, etc.
@samogami Did I capture this right? Should there be a note, or maybe something added to the closed functionality section? Do these issues happen on non-closed products?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Good point, I agree it's too much of a stretch to apply WCAG to hardware, like a physical screen. That said, software can have closed functionality. EN 301 549 addresses closed functionality software while Section 508 does not. For example, a company develops software to run in kiosk mode on a variety of tablet hardware. Such software must be evaluated for EU procurement. If the scope of the WCAG2ICT task force allows us, I'm in favor of addressing closed functionality software — including under 1.4.11. |
I've evaluated streaming apps on a TV set top box. Apps in this environment are arguably not closed. For example, it lets me attach my own wired USB keyboard in lieu of the TV remote D-pad. Yet the app and the platform provide no screenshot capability. Next time I audit such apps I plan to try an HDMI capture device to evaluate colors. For purposes of WCAG2ICT though we can just say 1.4.11 applies, and leave the screen capture difficulties to techniques (out of scope). |
|
I agree with @mitchellevan that we need to address products with closed functionality software. I'd also point out that Section 508 also defines closed functionality Closed Functionality. Characteristics that limit functionality or prevent a user from attaching or installing assistive technology. Examples of ICT with closed functionality are self-service machines, information kiosks, set-top boxes, fax machines, calculators, and computers that are locked down so that users may not adjust settings due to a policy such as Desktop Core Configuration. So a PC that is locked down to prevent turning on certain accessibility features could be considered a product closed functionality. |
|
I agree with @mitchellevan on color values - even though color values may be difficult to obtain doesn't mean the criteria could not be applied. Some color values are difficult to obtain in software as well because some platforms have color profiles that change the colors. |
|
@GreggVan @mitchellevan We are not talking about applying these requirements to closed product hardware. However, the problem exists today where this requirement is directly being applied to closed product software in the EN 301 549. So there does need to be something said that this type of requirement often doesn't make sense to apply to non-web software on closed functionality products - because there may be hardware limitations where this requirement does not make sense to apply. This is why the conversation is so important. Here is the quoted text from the EN:
There are no notes, nor pointers to alternate Closed functionality requirements. It is being applied across the board to all non-web software. WCAG2ICT can, and should, point out these complications. |
|
The comments all had to do with hardware displays
If someone is writing software— they have no knowledge of the hardware it will run on.
If we are talking about software tied to a particular piece of hardware — that willl end up being a closed product - which we don’t cover.
Can you give an example of software that would run into the problem they cite — that is not on a closed product. I may be missed remembering, but I thought that the examples they were giving were all close products, examples. Hence my comment.
Do we have examples of software that would run into the problem they cite — that is not on a closed product.??
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Feb 27, 2023, at 10:42 AM, Mary Jo Mueller ***@***.***> wrote:
@GreggVan <https://github.com/GreggVan> @mitchellevan <https://github.com/mitchellevan> We are not talking about applying these requirements to closed product hardware. However, the problem exists today where this requirement is directly being applied to closed product software in the EN 301 549. So there does need to be something said that this type of requirement often doesn't make sense to apply to non-web software on closed functionality products. This is why the conversation is so important. Here is the quoted text from the EN:
11.1.4.11 Non-text contrast
Where ICT is non-web software that provides a user interface, it shall satisfy WCAG 2.1 Success Criterion 1.4.11 Non- text Contrast.
—
Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXUEWLL66HY5734TBQ3WZTYSDANCNFSM6AAAAAAUGQHYEQ>.
You are receiving this because you were mentioned.
|
|
@GreggVan I'm sure you recall that we do have a section in the WCAG2ICT note that does talks about SC that are problematic for closed functionality. It is fully within the scope of this Task Force to talk about and add content to the existing section about the application of WCAG to non-web software on products with closed functionality. See the WCAG2ICT Task Force work statement Scope of work section that includes the following bullet:
For non-web software on products with closed functionality, those writing the software will often know exactly what hardware it is run on. They may not know the specific default contrast of the hardware, but will know whether or not they can modify colors/contrast. At the very least, I think we do need to say something about this being a problematic requirement for non-web software on products with closed functionality. If only to note there are instances where the closed functionality software has no ability to control the contrast of non-text content in the UI. Perhaps the following note would suffice:
|
incidentally, this holds true just the same way (or even more so, actually) for web development ... authors are not in control of an end user's actual experience as they don't know what device, OS, system settings, user settings are in effect ... which is why the SC (and the text contrast SC) only care about the colours as defined in the underlying markup/stylesheets, rather than the "as measured on the actual screen" colours/contrasts. so i'm not quite sure why this is seen as contentious in the context of non-web ICT |
|
@patrickhlauke I am contending that this SC should not be applied to all non-web software, as there are hardware implications for certain closed functionality products where there is no "platform software" nor "user agent" to be able to utilize the existing exception in the SC. It seems there should be an allowable exception because the non-text content's contrast is not controllable by the non-web software author as a more general exception. Web content always has some "user agent" and sometimes also a platform software, so it is easy to see where the exception would apply. |
|
I agree with @maryjom. wcag2ict is about non-web software and documents. To the comment above:
I disagree with this statement and other discussions about SC where some dismiss the mention of devices as examples. Some web developers, printers, cameras, TVs, IoT devices, and others, developers must know the hardware that their software is running on. Putting web centric norms and values without considering the diversity of software and ICT creates SC that are impossible to implement, provide no greater accessibility, and discourage innovation. I am not advocating the removal of contrast requirements or other SC that are determined to be appropriate for other ICT, including closed systems. When applying WCAG to ITC, hardware, closed systems, and other ITC examples need to be open to discussion and should not be dismissed. Examples that include hardware can provide contextual use of devices/situations that need to be exempt or provide a different way to meet SC. For this particular SC, I agree with the direction of @maryjom note:
|
|
unless i'm misreading @samogami's message, I'm a bit puzzled by the assertion that requiring non-text contrast for non-web contexts would stifle innovation. there are certainly cases where an author/developer has no direct control over, say, the exact colours used (as it may be given by the underlying system itself and outside of their influence), but there are just as many scenarios where developers of non-web ICT do have complete control over colour combinations used (think native Windows/macOS/Linux applications or similar). so the discussion is not about "stifling innovation", but more generally about making sure authors aren't on the hook for things they can't directly control in the environment that they're operating in. |
|
So could this possibly be a good note? NOTE: There are instances in products with closed functionality where the appearance of the non-text content is determined by the hardware and not modifiable by the author (rather than determined by a user agent or platform software); these instances should fit into the exception for this SC. |
|
I agree with Patrick - for me non-text contrast issues are just as important on closed systems like printers as they are on websites and mobile apps. My printer has a full color screen and icons with low contrast and that makes a big impact on me. Point of sale devices, transaction screens often have icons with low vision but most have the capability to create better contrast icons. Many closed systems use platforms like Android to deliver the content on LED screens and where they do have control of the colors used it would seem this requirement should be applicable. |
|
@mraccess77 I don't disagree that there are some closed systems where the author CAN control the colors used - because that closed system's display has the full color choice capabilities. However, there are also some closed systems where there are no colors or limited colors to choose (like only foreground colors, some with limited numbers of colors (like 8) and the background is not a settable color) and the software author has no, or highly limited, control of the colors that appear on the screen. These are the cases we'd like to cover. Software authors can't make a program overcome limitations of the hardware/firmware that is part of the display. That is what my proposed note is trying to address. |
|
@maryjom I don't disagree that some software can't control those aspects - I was not responding to you.r comment. I agree with your note. I was responding to another person's comment on the notion that non-text contrast was a web-centric thing because the hardware is known. To me non-text contrast is web-centric and websites don't know the hardware either - the website could be displayed on a VR headset or a TV. One other aspect I would like to bring up is when the hardware and software are both controllable for the same organization and the choice is then made to use insufficient contrast when contrasting combinations would be available. |
|
@mraccess77 Thanks for the clarification. I agree that when hardware and software are both controllable by the same organization that choices should be made to ensure good contrast. That is outside of the scope of what the WCAG2ICT can really comment on. As Gregg had correctly mentioned, we don't tackle hardware issues - outside of our scope. We stick a little more tightly to thinking only about the application of WCAG requirements to the wide variety of software and where doing so may not work so well. I will update my proposal to include the note I drafted and send it to the TF for review. |
|
I apologies for the confusion that my comment above might of caused. I have modified it in hopes of making it more understandable. |
|
Update made to the note on the closed functionality bullet to address survey comments from Sam, Mitchell and Fernanda. From Success Criterion 1.4.11:
Guidance When Applying Success Criterion 1.4.11 to Non-Web Documents and Software:This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.11 (also provided below), replacing “user agent” with “user agent or platform software”. With these substitutions, it would read:
NOTE NOTE In Appendix A. Success Criteria Problematic for Closed Functionality add the following:
Since the WCAG 2.2 definition of "state" needs no word substitutions or interpretation, add the following bullet to the Glossary Items that Apply to All Technologies section.
|
|
Should "user agent or" be added before platform here "An example of appearance modification by the author is content that sets the visual style of a control, such as a color or border, to differ from the default style for the platform." |
|
@mraccess77 Good point...modified the comment above to add "user agent" to the note. |
|
Incorporating survey results (which showed a high level of preference for Option 1), comments in the survey, and discussion from the 30 March meeting. The SC guidance itself is stable (from the previous proposal comment, so we are now focusing on the guidance and notes for Appendix A: Success Criteria Problematic for Closed Functionality. In Appendix A. Success Criteria Problematic for Closed Functionality add the following:
|
|
As @mitchellevan notes on the list, the 508 approach to contrast for closed hardware is modest. See: 402.4 Characters on Display Screens
Note that 508 does not (at present) have a contrast requirement for non-text content. I will also note that this contrast requirements is an analog to the requirement under ADA (and ABA) for signage. The Access Board had a "Guide to the Standards" which includes the question, Why isn’t a minimum level of color contrast between characters and the background specified in the Standards?
|
|
Adding in Mitchell's comment sent via email to this issue so we can track everything back to this issue.
@mitchellevan @bruce-usab Yes, it is modest in the hardware requirements at best but I don't think there's any argument that you can't hold the software responsible for the lack of hardware capabilities. And there are testing difficulties for this SC regardless. Maybe you can do a direct screen capture, but if you can't and the color information is not programmatically available, this is a much less testable requirement by a 3rd party. The software author would have to confirm they used whatever methods were available to them to make color choices that provide sufficient contrast. |
|
In the 6 April meeting the group decided to keep language as-is and merge into editor's draft. The comment about other potential sufficient testing was added to a wiki page where we can keep such things. The group wanted to try to keep away from developing sufficient test techniques as it is considered out of scope. We'll see what the AG WG and public review prove out in this space. |
|
The TF reached consensus on the guidance for SC 1.4.11 on 6 April. The AG WG reviewed 1.4.11 in the 3rd content review and approved the content on 25 July. |
From Success Criterion 1.4.11:
Guidance When Applying Success Criterion 1.4.11 to Non-Web Documents and Software:
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.11 (also provided below), replacing “user agent” with “user agent or platform software”.
With these substitutions, it would read:
NOTE
An example of appearance modification by the author is content that sets the visual style of a control, such as a color or border, to differ from the default style for the platform.
NOTE
See also the discussion on Closed Functionality.
In Appendix A. Success Criteria Problematic for Closed Functionality add the following:
Since the WCAG 2.2 definition of "state" needs no word substitutions or interpretation, add the following bullet to the Glossary Items that Apply to All Technologies section.
The text was updated successfully, but these errors were encountered: