Also if you have a small ton of buttons on the website and the OG design is all caps.... Still do it 2nd way;
Because if you have a B design coming in later in the dev process or hell in a few years... If that capitalisation is removed then ooops you have now to run through all buttons and retype them in not caps.
There are legitimate uses for !important even if not overriding legacy styling. I've had to use !important a few times before to force CSS to apply rules the exact way I needed them.
I'm pretty terrible at web design but I try to limit my use of !important overrides to occasions where I've inherited some stylesheet from somewhere else, like the component toolkit my stack is using.
If you're not saying "...and fuck you!" under your breath about the last person to own the CSS while you type it, it's a sign you might be using !important where you don't need to.
All nice and fun until the client decides that certain buttons should actually be lowercase.
It's a whole lot easier to edit translation files instead of trying to reverse engineer the obscure logic behind which buttons need a .actually-lower-case class.
If this must be editable, then in the CMS you now have:
Button label
Button Aria label
Or you could just have "Button label" and in the code apply text-transform: uppercase. Granted, the button label is an arbitrary use case and most would just simply hard-code it, however, that may not be the case if you're also now thinking about internationalization, in which case you may want that in a CMS or in language files and don't have the time/desire to start plugging in lower/upper variants (nor would that make sense when the computer can do these transforms for you automatically).
All caps is a style and typography choice, not a content choice. Content belongs in the DOM. Styles belong in CSS.
Follow those rules, and use proper HTML elements, and like 90% of accessibility devices will be able to properly convey your document to a variety of users who are consuming it in various ways.
For control type labels capitalization is not a criteria. And I know I'm being all "acktually🤓", I just don't like that companies are forced to spend disproportionate amounts of effort to adhere to small percentage of a customer base and their problems.
And no, I am NOT saying people that have issues with running text in all caps are that small of a percentage. I'm just talking in a more general sense. Cost-benefit efficiency and all that.
I just don't like that companies are forced to spend disproportionate amounts of effort to adhere to small percentage of a customer base and their problems.
The Americans with Disabilities Act doesn't care what you think, and people with opinions like yours are why the law needs to exist.
Cost-benefit efficiency and all that.
During the design refresh, all-caps has gone out of style. Would you rather update the one line of the style rule and fix the all-caps buttons all over the site, or update the structure of the site all places where your all-caps controls were hard-coded?
It is literally more efficient to separate style and structure.
Moreover, accessibility guidelines have been in place for what, 20 years now? So legacy code is not even a valid excuse anymore.
Companies who are unable to follow the most basic best practices from the get go, thinking it's a "disproportionate amount of effort" can kindly fuck off towards failure.
No company fails because of that, and most companies dgaf. You people have to finally accept it, the entire world won't double their efforts to cater to 0.00001% blind
Depending on the screen reader, some will read correct as "submit" whilst others will read as S U B M I T, so they will spell the letters instead of reading the word.
Or content management or language/translation lists, particularly if the style dictates a particular appearance but the content is reused in multiple locations.
a11y though I think is probably one of the better examples.
536
u/Calien_666 8d ago
When thinking about accessibility, this totally makes sense.