Some old lessons have to be continuously relearned and reinforced, and not mixing content and style is a familiar friend to revisit whenever talking about accessible data.
To be clear, separating style does not mean avoiding the style attribute and putting all your CSS in a
separate file, even if that is another good practice we’ll get back to. What
separation of style refers to is not expecting the visual appearance of your
content to convey meaning to readers. Style is just a layer between your
markup and the device that renders it, not an intrinsic quality you can rely
on to say anything about your content. Typographic conventions had to convey
meaning in print because that was all that was available, and are still
useful for sighted readers, but are the wrong place now to be carrying
meaning.
Some reading systems will give you the full power of CSS, while others won’t even have a screen for reading. Some readers will visually read your content, while others will be using nonvisual methods. If only the visual rendering of your content conveys meaning to the reader, you’re failing a major accessibility test. Leave style in that in-between layer where it targets visual readers, and keep your focus on the quality of your markup so that everyone wins.
The most basic rule of thumb to remember is that if you remove the CSS from your ebook, you should still be able to extract the same meaning from it as though nothing had changed. Your markup is what should ultimately be conveying your meaning. If you rely solely on position or color or whatever other stylistic flair you might devise, you’re taking away the ability of a segment of your readers to understand the content.
But there is something to be said for cleanly separating content from style
at the file level, too. The cascading nature of styles means that the
declaration closest to the element to be rendered wins. If you tack style attributes all over your content you can
interfere with the ability of a reader to apply an alternate style sheet to
improve the contrast, for example, or to change the color scheme, as the
local definition may override the problem the reader is attempting to fix.
Consequently, suggesting that you avoid the style attribute like the plague is actually not an
overstatement.
More realistically, though, you should be able to use CSS classes for your
needs. If, for some reason, you do have to add a style attribute, though, avoid using it to apply general
stylistic formatting. Keeping your style definitions in a separate file
simplifies their maintenance and facilitates their re-use on the production
side, anyway, and this simple standard practice nets you an accessibility
benefit.