I’ve recently read The Ballad of Text Overflow (opens in new window) and it made me remember past discussions with some content providers that were not happy when their text broke in unexpected places. I tried to explain the problem and that the quickest solution is just to let browsers break the text based on remaining space.
In most cases it was OK, but I could feel that they were a bit disappointed. And I told them that I am also not happy about it but we do not have a lot of options. I’ve shown them how to fix it in so called rich-text fields in the content management system (CMS) – by using the so called soft-hypen special command (­). But there were still titles. Titles in most CMS systems don’t support special characters. And therefore titles must be solved centralized – with CSS. But how can we do it?
Responsive design doesn’t magically solve breaking long words correctly
As mentioned – when we have access to raw HTML we can always use the soft-hypen (­) special “command” and it will be respected by all browsers. So we can define where the word will broke by ourselves. So if we are familiar with grammar and soft-hypen and we have access to edit HTML of the content, then we can fix this problem correctly.
But what if we can only write “plain text”? A lot of fields in the CMS only support plain text and if we try to use soft-hypens they will just be displayed and ruining wanted text. Because CMS doesn’t render them as they should have.
So – solution has to be made with CSS and we would expect that responsive design will fix it automatically for us. Well, only using responsive design and for example mobile first will not automatically resolve potential problems with long words. Some languages will not be affected, and maybe we will never have a problem with that, as we will not use long words. But some languages and some content needs to support very long words and there we can have a problem. If we also have to conform to WCAG 2.1 on levels A and AA we most definitely have a problem.
Making design work at 320px widths should not be a problem
But it can be. Again – if we think of languages that have long words (like for example German, Norwegian, Finnish and many many others) we quickly have to support titles with long words. And with titles and their larger fonts we quickly get into troubles when we want them to work on 320px. And not only want – we must make it work on 320px according to WCAG:
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
WCAG Success Criterion 1.4.10 Reflow (opens in new window)
– Vertical scrolling content at a width equivalent to 320 CSS pixels;
– Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Except for parts of the content which require two-dimensional layout for usage or meaning.
These “mobile first” days a 320px width is not a problem for our components. Some very advanced patterns and widgets may struggle a bit, but I think that both designers and developers can fix it quite easy.
But this is again not the case with long words with larger fonts that can quickly become a hidden problem. Hidden because neither designers nor developers test with extremes and then some day in the future a content provider needs to have a long word as a title.
I guess some more experienced designers and developers thought of that and made all texts to break based on design (“word-break” CSS property allows “break-all”). But the content provider could treat it as a bug. But I am afraid that in most cases this problem is forgotten, as for example is with Bootstrap (5). If you test your default Bootstrap design with 320px width and very long title you will quickly discover it will break the design.
Possible solutions
Often we have multiple solutions, and this is also the case here. Let’s investigate possibilities and try to come with conclusion.
CSS property hypens – best solution but not ready (yet)
When browser has a dictionary of all words and how they have to be grammatically hyphenated it surely is the best solution. Setting “hypens:auto” in CSS is the optimal solution but unfortunately not supported enough to be the final one.
I think that main problem here is to get all the words in all languages and the rules on how these words can break. While I did not investigate the source code of the browsers I am quite certain that is the main problem.
You can check the support of hypens on Mozilla Developer Network (opens in new window) and check it yourself.
CSS property word-break:break-all – simplest solution but disrespecting grammar
If we just let CSS break the words wherever it is best for it’s container you have a robust solution. But as mentioned – some people will dislike pages that break grammar. So I think your stakeholders and content editors should be at least informed about that. It will work in any scenario, but it will not be pretty.
Allow the content to be shy – soft-hypens to the rescue – currently best solution
I like the idea of content providers in charge. They are crucial in making things accessible, so they should also have the possibility to decide when words will break and how. I think I can generalize a bit here – I like to think that typical content provider likes grammar. So they like to decide where the words and titles will break.
With that defined – it is up to developers to provide a solution. Allow soft-hypens in all types of content that is displayed to the end users. Titles, descriptions, paragraphs, even icons and filenames that are displayed should support them. It’s not an easy task in some cases and it sometimes probably also mean to have multiple fields in the database to make it work (think file URL and file name displayed to users), but it is the most sustainable solution until automatic hypens will get total support.
Content providers then need proper training and testing, let’s not forget about that please.
Conclusion – make it work today and check when auto hypens will work
As mentioned in the solutions – automatically breaking all kind of words in all kind of languages is currently not possible. While we wait for it we should enable content providers with a technique that allows them to do proper work – allow soft hypens (­) in all fields possible.
This will make grammar police happy and it will also prevent you failing WCAG success criterion 1.4.10.
I’ve tested different solutions with some extremely long (and rare) words and invite you to check the tests for yourself.
