TOPIC:

Hi Xerte forums!

Long time user, first time poster here - I hope someone can point me in the right direction.

---

Some background:
I'm using the Xerte Online Toolkits theme and I'm trying to support users adding a tiny bit of CSS - essentially some branding colours for the headerblock and specifically link text: for example
#x_mainHolder a {color: DarkGreen;} )

---

My problem:
When the colours are inverted, some link text colour contrast falls below what's needed for WCAG. Therefore what I want to do is shift the colours slightly when in the inverted mode (e.g. to a light green)

However, I don't have something to hook onto to fix this in a simple way
(for example .filter_inv #x_mainHolder a {color: LightGreen;} )

It looks to me that when you switch to one of the accessibility modes (inverted/black on yellow), this simply replaces the current stylesheet with the target accessible one (e.g. default.css > highcontrast.css). There's also some javascript that looks to try and overwrite some of the colours too.

---

My question:
Am I missing a trick and approaching this all wrong? (sorry I'm not a developer). Ideally I would not like to have to overwrite/maintain the base themes and leave this small amount of theming with the end users.

Hi
I'm afraid we took the decision a while back to stop using the .filter_inv etc because it became unsustainable. I can't remember exactly when but it's years not months! The problem was that the simple functionality that worked when we only included the default black and white theme with image buttons was easy to maintain at that time. But since we started including more themes and more ranges of colours in themes as well as the wysiwyg editor then it became impossible to reliably maintain the inverted and black on yellow themes. So you're right when either of those options are chosen by a user we simply switch to those themes and override everything else that we can. It's not perfect because authors can hard code colours or apply colours manually using the wysiwyg editor but at least as far as we can control we give the importance to the end user who wants to choose one of those two accessible themes. Likewise themes can be switched with a url parameter although authors can disable that.
You can probably add script in projects or in your own custom theme to do what you want but I'm not sure it's worth the effort and risk in terms of future proofing. The best solution is to create some custom themes that the authors can choose from and explain that the two accessibility themes need to take priority when users choose them.
HTH
Ron

Hi Ron - thanks for your super speedy reply!

I appreciate the decision to make this easier to maintain. For us, with many different departments/groups all looking to have their own "branding" we were also trying to avoid idea of having to maintain themes centrally and just have a few CSS tweaks for authors.

Going forward, we will keep to just adding simple CSS tweaks in the projects themselves controlled by authors, but now they'll have to "go with the flow" for the inverted/black on yellow themes and not have extra colour branding. A simple: a {color: DarkGreen;}) will be simply overwritten by the accessible themes (previously, I had extra CSS selectors so the theme switch didn't work).

Thanks again!

P.S. hard coded colours are a constant problem with most users unaware! I wonder if it's possible to catch the <span> and use a script to overwrite this or would this get too messy?