PS - This all falls under 508 Compliance and WCAG.
I am curious what you mean by "changes it for the worse."
If it's that it lowers the contrast in some areas, that is a bug and we'd like to know of the specifics of what you are seeing so that we may file it and fix it.
If it is that it causes some things to be off-brand to your community's theme, that is by design. It is meant as a theme override and a way of guaranteeing that Jive is in WCAG compliance for the end user that needs it. It is in compliance with specific, measurable WCAG contrast ratios.
These CSS settings are not meant to be edited. This is the safety net for end users who do need higher contrast for readability's sake. Per the notes in the CSS file itself:
* The goal of this style sheet is to modify the look and feel of the application to meet WCAG guidelines,
* in instances where that's not possible without sacrificing the application's normal appearance. This
* style sheet stacks on top of jive.css and friends, and will be conditionally included when the user sets
* a preference for accessible presentation.
While I recognize that it can be frustrating that it can put a site off-brand – keep in mind that this is, as stated, a safety net for users in need of a high-contrast presentation that might not otherwise be getting it from the main community theme.
If you are finding that you need to have a high contrast theme for accessibility that is still on-brand for a community, you should look into satisfying those WCAG contrast settings within your main published theme.
Brent, I realize not being blue is off brand for you, but you could help that banner look better in the second one if you used a transparent PNG file for the white letters of your community's logo. Then it wouldn't have the remnant blue box over the dark gray background if high-contrast is set. I hope that's helpful.
Coincidentally, just based on looking at that header alone in the first example, your contrasts seem to be up to par for contrast ratios. If you've followed through elsewhere with contrasts in your theme, you might find that users that need high contrast won't be reaching for that preference. Additionally, my suspicion is that many users that need high-contrast assistance rely on it at the OS level and may not seek out the setting within Jive. Still, we are on the hook to provide the setting to satisfy certain Section 508 and WCAG requirements.
Following up with what you were saying John Lascurettes, as you can see our community would not qualify for 508 Compliance / WCAG when they turn on the "High Contrast".
Thanks for any insight on this situation!
Nathaniel Elliott, I'm curious if this is on a cloud instance or not. It definitely should not happen with a cloud instance and a bug should get filed on that if it is – if you're on cloud, please create a support case and mention me so Support will flag me when it gets filed. What should happen on any cloud instance is more akin to what you're seeing with Brent's screenshots above.
However, I'm going to guess, based on the styling of your search box (something you can't do with the Theming Tool) that you have done a themed overlay. If it is on a hosted or on-prem instance, unfortunately, it's likely beyond my ability to offer any help beyond the advice I offer below. The thing with advance theming overlays, the type where you are rewriting files (and not just using the Theming Tool configuration settings) is that you can easily alter or remove a DOM hook that the accessibility stylesheet is relying on.
There are a few things you can try doing (assuming you've done and advanced theme):
- You could remove the ability to select the high-contrast setting (someone with deeper engineering knowledge would have to help out with that). You'd probably also have to do a database query to reset user's values that have it set to "on" back to "off".
- You could theme the jive-wcag.css file, overlaying it anew with new values that will work with your chosen customization.
- You could find the templates or CSS that you changed that affect the areas that are in conflict with the accessibility styles and see if you can find a way to "repair" them or make them harmonious with high-contrast style sheet.
BTW, it's recommended to not combine the two methods (Theming Tool configuration and advance theming overlays). Amber Orenstein might be able to shed more detailed light on that if you would like it. There are exceptions to the rule, mainly around using advanced theming for phrase substitution and the Theming Tool for site styling.
This is an on-prem instance of jive. Thanks for your thoughts on this as a whole, here are my responses:
- Great idea, I think I will remove this ability for users. I loved the idea but it is hard to implement on an on-prem version!
- Where would I find this jive-wcag.css file? Am I missing it in the theme files themselves? I would LOVE this ability and leads back to my original post.
Understandable with the final point, we only use one! The theme files in the backend. Simple code but easier done there. Thanks again for all your help / being willing to look into this John Lascurettes!
We learned that there is no way to 'customize' this. If anyone finds a work around to do so, let me know and we will put THAT as the correct answer.