There are a lot of great improvements to the Carleton web template on the horizon when we launch cuTheme. Something we are excited for is the removal of the ability to edit a page by adding HTML, Javascript, and styling.
In this post we outline why we need to make this critical move. There are several reasons that having the ability on hand to edit HTML is a liability for your end users.
Accessibility
If there is one good reason to remove the ability to edit HTML code it is the potential for rogue code to harm the accessibility of a web page.
The example often used to show the harm HTML code can do is coloured text. We have very dark text for a reason – it contrasts well with our light background and colour contrast is key to the legibility and scanability of text. With the HTML editor in place a website maintainer could place very light text on our white background making it invisible to those with vision challenges. Keeping the text within certain tones makes sure the text is as legible as possible. Remember, someone does not have to have particularly bad eyesight in order to find it a strain to make out light text on a light background.
People also use HTML to colour code text, giving it meanings that are implicit but only to those who can perceive them. Changing text to render in red, amber, and green to illustrate bad, neutral, or good items only works if people can view those colours. One in twelve of some demographics can’t distinguish red from green, making this practice misleading and even possibly dangerous.
That’s the classic example. But in fact a more important instance of changing the attributes of a font comes with using HTML and JavaScript to change the size and weight of text. Imagine you want to write the word Warning in a way that makes it more noticeable. One way would be to make the text much bigger using HTML code. But by doing that you are confusing users especially those whose neurodivergence manifest in the form of a difficulty in how a page of information is laid out.
By using HTML to show text at the same or similar size to one of our subheadings, the user believes the word Warning denotes a section of the page when it is doesn’t. It then becomes unclear what is a page section and what it isn’t. And if you use it to set the size of the text for a heading, then you are going to confuse humans and the screen readers they employ.
Usability
That also illustrates a good example in the crossover between usability and accessibility. Usability – how easy it is to move around, identify, take in and interact with page content on a website – is affected by many of the same concerns that affect accessibility.
People also use HTML to manipulate colour of links. Links in text in the CCMS render as red, with the exact tone double checked to match the colour contrasts determined by W3C. If that colour is then used to highlight something, people assume it is a link. When they can’t click on it they are confused.
Consistency
That previous illustration also refers to consistency. Another practice is to use a different colour on links so some are red and some are blue. Elsewhere a subheading in the text might be blue. This means someone might click on it, only to find nothing happens. Confusion all around!
Ease of maintenance
But why limit confusion to the front end of a website when an editor can also cause mayhem in the backend too? Remember that not everyone has the coding knowledge that one team member might possess. That’s fine when the coding guru is around, but if they win the lottery (or go on vacation for a week) and aren’t available then the colleague who steps in to make a change might be left scratching their head as to how to edit the page. They are confronted by a set of code they don’t understand. The most likely thing is that they will break the code making the page even more unpredictable to users.
Risk of errors
Introducing HTML code – or trying to fix it when its creator has gone on vacation – can also create havoc with other elements on the page. Why? Because the CCMS template is created using a combination of HTML, CSS, and PHP, but also a series of Javascript libraries. Injecting code into the page can interfere with that. In the very simplest example, failing to close a font tag code make the rest of the text on the page red.
We have a team of developers who spend days on end testing for how content can break the code in the template. Let’s make not make their jobs harder.
Security
Finally, there is the safety aspect. With an HTML editor enabled, there is always the fear that malicious actors can inject code that does harm to the site or the whole network. HTML injection attacks involve inserting malicious HTML elements or tags into the content created with the editor. This can result in the manipulation of the page’s structure and content, potentially leading to security vulnerabilities or phishing attempts. URLs can be placed in a page that lead to websites whose owners have criminal intent, for instance. Similarly, JavaScript can be injected as a potentially more powerful security threat than HTML.
In the future we will give some guidance on how to achieve some of the things previously rendered by adding code in the page. Until then, we will give you time to mourn loss of the
SUPERPOWERS
associated with the HTML editor.