You need to turn on Javascript in your browser to use this site!

CSS Inline styles & accessibility | Nomensa

CSS Inline styles and why they are considered harmful for accessibility

Posted on

4 minutes, 39 seconds


Since the mid 1990s web developers have had an ever increasing amount of control over the presentation of the web pages that they develop. This is largely due to the introduction of CSS (cascading style sheets) and its adoption amongst major browser vendors, both past and present. Although the adoption of the CSS specification has not been without issues it has made it possible for web developers to build visually imaginative and engaging web pages and user interfaces. Since the inception of CSS there have been a number of different ways to alter the presentation of elements within an HTML or XML document:

  1. Styles can be declared in a separate file and linked to from the HTML document. The styles declared within this external file will be parsed and applied to relevant elements within the HTML document;
  2. Styles can be embedded directly into the of the HTML document. These styles should be nested between tags and will be applied to the HTML document in much the same way as styles contained in an external style sheet;
  3. Styles can be embedded directly into elements within the HTML by making use of the style attribute. These styles are rendered in much the same way as the techniques identified above, although on a per-element-basis.


This is a heading


The first of the techniques identified above is generally the preferred method for styling content on web pages. It is considered by many to be the cleanest and most maintainable solution as it constitutes a clear separation between structure (HTML) and style (CSS). The second method should not behave any differently than the first method. However, it presents a potential maintainability issue since the HTML and the associated styles are tightly coupled to one another. This can make it harder to split work between different members of a team and can bloat the HTML file. The third method identified above presents the most problematic case. If styles are embedded directly into HTML elements using the style attribute the HTML can become hard to read (and thus maintain) and can present accessibility issues for some visitors to your website. The following sections attempt to identify some of the issues associated with inline styles.



Over the past 20 years experts in the field of client-side web development have expressed concerns over the use of inline styles. Developers often find that maintaining complex HTML documents is made significantly harder if a large amount of presentational data is embedded within the document source. The preferred method for many is to make use of external stylesheets. Styles declared in external stylesheets are applied by referencing element types, classes and unique ids within the HTML document. It could be said that styles declared in external stylesheets are ‘unobtrusive’ since they are not tightly coupled to specific pages or elements. For many this separation of structure (HTML) and presentation (CSS) is a logical step towards improved maintainability.



Some people will make use of custom style sheets when browsing the internet. People with severe colour blindness or other visual impairments may have difficulties reading content online and will be most likely to make use of custom style sheets. Custom style sheets are stored on the users’ computer and will be used by them to view many (if not all) websites on the internet. They make it possible for people to define colour combinations and font sizes that make it easier for them to read content on web pages comfortably. Embedded styles will almost always override externally linked style sheets (including custom, user defined, style sheets). For this reason the use of inline styles should be avoided. For example, if the font size of a heading was declared inline a person who needed to make the font larger using a custom style sheet would find it hard (if not impossible) to do so. This can prevent people from being able to access content on your website in a manner that is most comfortable for them.



In recent years some of the most popular browsers have made it possible to override ANY styles within a web page (including inline styles). This is a really promising thing for accessibility. However, people who are stuck using older or less popular browsers are more likely to encounter issues with inline styles. In conclusion I would urge developers to be mindful of accessibility when creating CSS styles for web development projects. It really is no more difficult to separate CSS styles from HTML mark up. In fact quite the opposite is true. If CSS rules are declared in external style sheets the resulting HTML mark up is likely to offer significantly improved manageability as is the actual CSS used to style the website. However, of more importance is the affect this has on the accessibility of your website. If all styles are contained within externally linked style sheets people will be much more able to override the default presentation of elements on the page. This is likely to make it easier for some visitors to your website to engage with the content contained within.


Start building accessibility into your projects at the beginning to save time and money, don’t just leave it hanging on the backlog letting it gather up dust. Drill it in.

If you would like Nomensa to help you with your accessibility challenges or to provide you with an accessibility evaluation of your website/mobile app, please don’t hesitate to get in touch.

Take a full look at the web accessibility services that we offer.

Related posts

  1. What’s new in WCAG 2.2


    What’s new in WCAG 2.2

    Discover the latest advancements in web accessibility with WCAG 2.2. From new success criteria focusing on mobile interaction to cognitive disability support, learn how these…

We'd love to hear from you

We drive commercial value for our clients by creating experiences that engage and delight the people they touch.

Email us:

Call us:
+44 (0) 117 929 7333

Please update your browser to view this site!