Add text-transform variables

[swashbuck]

Subject of the enhancement

Add variables to control the text-transform properties for all font mixins. For example, add to .item-title() and .instruction-text() in _less/font-mixins.less.

Variable naming convention could be like @item-title-text-transform and @instruction-text-transform.

[kirsty-hames]

It's worth noting the accessibility impacts, large sections of text set with a text-transform value of uppercase may be difficult for people with cognitive concerns such as Dyslexia to read. See MDN for reference.

However, we could always add a 'remove text transform' option to the Visua11y Readability section?

[swashbuck]

However, we could always add a 'remove text transform' option to the Visua11y Readability section?

@kirsty-hames Yep, I think that would be a great idea for Visua11y.

Anecdotally, this usually seems to come up as a request for button text, but we might as well add it everywhere?

[kirsty-hames]

Anecdotally, this usually seems to come up as a request for button text, but we might as well add it everywhere?

The request has typicaly been for button text for me too but I've also had it requested for titles. Maybe we just avoid body text?

[swashbuck]

The request has typicaly been for button text for me too but I've also had it requested for titles. Maybe we just avoid body text?

Yeah, that makes sense. I've never had it requested for body text. That would be a nightmare to have to read.

[oliverfoster]

However, we could always add a 'remove text transform' option to the Visua11y Readability section?

I don't think users will know what a text transform is - I struggle to remember the difference between a text transform, a text decoration, a text emphasis and a font style.

Removing text transforms wouldn't always make the text more readable and will probably not help the user in many cases. Text transforms provide a way of creating visual uniformity from likely non-uniform source text without having to re-write the source text.

Bad but likely examples:

• Some text may have been written in capitalize style in the json and then have been transformed with css into uppercase
• Half of the titles may have been written in uppercase but all of the titles have been transformed with css into uppercase

This'll need a bit more thought I think before a user control is made available to modify or remove the transforms. It might just be a design issue?

https://www.elahub.net/3-capital-letters/

[kirsty-hames]

All very good points thanks @oliverfoster.

I have seen uppercase stated in some brand guidelines (titles and/or buttons). Some clients might not be aware of the impact on accessibility so this could always be a conversation.

Ideally, we shouldn't be encouraging styles that diminish accessibility however some clients will want this regardless. In that case, should this remain as a custom style if/when used? What are your thoughts @swashbuck?

[swashbuck]

@kirsty-hames I think we can still have theme variables for titles and buttons. We would just not expose those settings in the AAT. That way, only the theme designers can control it.

Ideally, we shouldn't be encouraging styles that diminish accessibility however some clients will want this regardless.

Yes, my thinking is that some clients will have a branding requirement to, for instance, change the button text to uppercase. The addition of variables will mainly be to assist the FED who must deal with these inflexible requirements.

[github-actions]

🎉 This issue has been resolved in version 9.19.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀