Photo of Jamie & Lion

The personal site of Jamie Knight, an autistic web developer, speaker and mountain biker who is never seen far from his plush sidekick Lion. View the Archive

Topics: Autism Development

Thoughts on Accessible CSS.

I caught Stuart Robson’s post about accessible CSS on twitter today. if you have not read it yet go read it now, i will wait.

Read it? interesting right?

The basic idea is we could reduce the amount of code required in some situations by allowing CSS to include ARIA attributes. This would remove the duplicated code from the HTML and instead move it into a single place in the CSS.

This is an interesting idea and i dont think the answer is completely clear cut. However, after mulling it over lunch i think i would come down on the “lets not” side of the dicussion.

I have two reasons, document semantics and code clarity.

So in no patricular order:

Document Semantics

HTML contains the structure and content of a document. I would consider ARIA roles part of the structure. They specifically tie elements to a structural meaning.

Having this structural content added via CSS means browsers would have to parse & process both the CSS & HTML before it had a semantically complete document. With external CSS this means two documents need downloading and processing before the full DOM can be built. This will slow down page rendering for very minimal benefit.

This also makes important accessibility APIs fragile, if for some reasons static assets are not loaded then the page looses some structure. At the BBC we serve static assets and HTML from separate systems. It’s very possible for pages to be served missing static assets.

Clarity

Stuart makes a good point about developers not adding all the myriad of CSS prefixs when they use experimental features.

He postulates adding more properties to be missed is a problem. From this point i can see how the argument that having a single CSS property beats dozens of attributes evolves.

However, i’m not sure this is positive. It hides the true nature of the propery (semantic meaning) behind the styling and selection mechnism (CSS selectors). This is confusing!

For me this decreases the clarity of the code in hand. It introduces an extra layer for a developer to understand. Further to this, the mechnism is unique and thus has to be understood as an exception. Adding exceptions and breaking a well understood (simple-ish) model in order to make something quicker or easier feels somewhat self defeating. Its something else to forget about and maintain etc.

I’m not looking forward to answering the question about which is better between adding attributes in HTML or CSS dozens of times.

I think keeping exceptions to a minimuim results in a more understandable, consistant and learnable technology.

What do you think? These are my reactions after mulling it for a bit. I can see it would be useful, but i dont think that justifies the complexity and clarity costs.

Published: 22 July 2012 | Categories: Permalink

Raspbain Official Release.

Just a quick one today, in case you did not already know the Raspbain OS has been adopted by the foundation as its official distribution for the raspberry pi.

Raspbian is the first Raspberry Pi optimised release. A loyal user recompiled all of the debain source tree to Pi optimised packages to make it. A phonomonal peice of work! The result is a 10-40% speedup!

I had been using the hexxeh raspbian images so decided to give the new release a whirl.

Getting up and running was quick and easy. On first firing up raspbian there is a quick setup wizzard that allows you to resize the parition and set overscan and the like. Very useful!

I wanted to try out the latest release of Chrome on the Pi. Mostly through curiosity. I could not get the instructions in hexxeh’s post to work so ended up just copying them from the linked text file line by line. This seemed to do the job! Chrome while slow now is a great start. Hopefully it will speed up a little as time goes on but its a step in the right direction.

It was good to see the new radio beta working well in chrome on the Pi. Nice to see the optimisation work taking effect!

Thats about it so far, i’m going to have a stab at compiling / installing XMBC and seeing how far i get with that.

Published: 21 July 2012 | Categories: Permalink

Responsive Contrast

Something which came up in work today was a discussion about contrast standards and responsive web design.

Do we need to consider different standards regarding contrast once we start thinking about users beyond the desktop?

The WCAG guidelines provide guidence on contrast. At the BBC we aim for AAA compliance but will take AA when AAA is not possible for some reason. However, when considering responsive design (sepecifically mobile) i am increasingly thinking that going for the higher contrast standard is a good thing.

Typically mobiles and tablets tend to have quite shiny screens. This is great for making colors pop but introduces issues around glare and brightness. A shiny screen such as the iPhone uses a powerful backlight in order to reduce reflections and glare. Even then sometimes (direct sunlight, brightness turned down) the screen can be hard to read.

Try turning the brightness on your phone or tablet way down and then using it in different places and at different times. While the low brightness works great in the dark evening, the following morning walking outside it renders the device unusable.

Using higher contrast helps to reduce this issue and keep the site more usable more of the time.

(Photo from: AnandTech iPhone 4 review)

Published: 10 July 2012 Permalink

Older Articles

Newer Articles