30 Days of Multimedia — Day 3 — Beginning Web Accessibility

This was something which I was thinking about, as I have been sort of doing some work with a group I belong to, and there are some things which I think should be done in terms of accessibility for stuff with web content:

  1. HTML should work without any CSS or JavaScript
  2. CSS should be used for presentational content
  3. JavaScript should only be used to enhance the HTML and CSS version

Now that is basically just a start, but since we want to keep things pretty simple for a single post here, I think we can start with these things right from the beginning.

HTML should work without any CSS or JavaScript

This is something that a lot of websites will fail because they are using things like JavaScript to control what is displayed, and what is not displayed.  While straight HTML often is pretty “boring” or hard to look at, but if it won’t work when presented as straight HTML, you are likely to have some problems.

When you are working with a content management system (such as WordPress here, or Weebly with that group I’m working with) often it can be difficult to know what all is happening unless you really work hard to dive into it.  With that in mind I will speak of testing in terms of a hand coded site, which I don’t really recommend except as an exercise to learn what is happening underneath, or if you wish to keep things extra simple.

I may write about some of the reasons you may want to hand code your site (usually with some programming to provide some dynamic content) in the next few weeks.  But for now we’re assuming that this is starting from the most basics.

HTML should be for content only and be semantic

This is a bit of a tricky thing  with what I am trying to say here I think.  First off, you HTML should “work” by itself.  That is it should look good enough that it makes sense by itself when it is rendered by the web browser.  But if we say that it is only for content, how do we make it “look good”?

Well the thing is, we don’t need it to actually look good we just need to make sure it makes sense.  So what I am looking at in front of me should never be what the HTML itself looks like:

Compter screen with a lot of different text on

Screenshot of WordPress post editing window

There are a few different things here which are presentational, and would not really work with straight HTML.  And one of those most obvious things is that the content is presented with three distinct columns of content.

Of course, with that said, that doesn’t mean that the way that this presents couldn’t actually work in terms of being straight HTML.  It would be a matter of making sure that what you want to present is in the right order.  And for me, this middle column content probably would present early than either the right or the left.

But when we start working with things in CSS then we can take stuff and present it in an “out-of-order” type way.  So I could have this centre edit window at the top (probably under that title bar that is currently at the top) but then the Categories and Tags from the right as the next elements.  Difficult, but not impossible.

So, the HTML has the content, and only worries about presentation from the perspective that when it displays without CSS and JavaScript it displays in a meaningful way.

Now in terms of that other bit…  The way that we actually write our code.

I can write all my code in ways that when I apply the CSS a person who is looking at it may have no idea that my code doesn’t really mean a lot:

For example:

<div class="paragraph">This is a paragraph</div>


<p>This is a paragraph</p>

The above will work but because we have ways to do it without reverting to stuff which fails to express what function the content serves, ideally we should work to use those methods wich already exist to handle the content.

For example use an <em> tag rather than a <font> tag to indicate that you are seeking emphasis.  In “days of yore” there were a lot of HTML tags which were presentational such as <center> or (dare I say it) <marquee>.  The latter was never well accepted.

We eventually decided that such things were not really good practices, so we have either done away with them, or made it so that we don’t use them.

CSS should be used for presentational content

This is maybe a bit confusing too.  So if I want something in the centre, what I do is somehow do it in the CSS, not in the HTML file.  Why?  Well in part because as originally designed HTML was designed to convey “information” and presentational (how things look) isn’t conveying information, it is providing a means (ideally) to convey of that information “a little better.”

So another thing, is that you don’t simply put the CSS in the HTML file.  I have seen this repeatedly.  Where there is a lot of code which ends up directly in the HTML file, which is CSS, or JavaScript, that should be elsewhere.

We have the ability to load files, now with how things can end up loading, if there is more file loads, it can end up slowing down the website, but this really should not be handled by dropping the file loads down to a single file (you can technically do this with a PNG file, where you can have the image and all the presentation of it all in the same file, but it’s more of a “scary trick” than anything practical).

Now here is a tricky bit, is whether or not certain “modern” CSS ways of handling thing should be done with CSS or with JavaScript the way it used to be done.  My feeling is that as CSS works, if you can do it with CSS.  Now here is a bit of a problem, how do you handle “older browsers”.

Depending on how you handle things, you might not need to worry, sure your gradient disappears, or your animation disappears, but if you can have it so that the CSS still works in older browsers you can probably be safe.

JavaScript should only be used to enhance the HTML and CSS version

This is a case where “if you don’t need it, then don’t do it,” or more “you can do it, but if you need it to do what you want, your site will not be accessible”.  So the specific issue I was looking at was an “Accordion Box” which was being used by this group which even though it consisted of simply the 3 different items, the code to do so consisted of almost 16K of CSS, with no idea how to go through this.

If the code isn’t self-explanatory it is going to need to be commented, and when I strip the code which is not HTML from that section, I end up with less than 2K, and a lot of that is actually HTML layers of different things, the code which is the actual content comes down to less than 256 bytes.  And everything else should have been in external files, and whatnot.  Now of course, we run into the case which can happen where we then end up with trying to load 12 CSS files, and 12 JavaScript files, because you don’t want to be loading content which isn’t needed, because well you see each byte counts.

Except it doesn’t.  It’s how fast a page will load which counts, and unless you are using both a rather modern browser, and your web server is very well setup, loading 30 files when a lot of that could be combined in probably 3 files, with maybe a maximum of 6 files (except for stuff like images), you probably are far better off trying to get some version which has as few different files as possible.

While I want to *code* my site with the form stuff in a nice set of files, it’s probably not doing a lot of good when I end up loading that set of files, and the accordion set of files, and the image set of files, and the video set of files, and the calendar set of files…

This is in a way sort of part of what is called DRY or “Don’t Repeat Yourself”.  Though not really.  It’s just that when you are doing things like this in development, it is important to make sure that when you see “this isn’t working” you have a means to relatively easily find where the problem might be, but when we are talking about how things will work when you are working with something like a web site, multiple files can slow things down dramatically.

But so can large files.  If I have something which is going to be a small image, like what is called a “favicon” I may want to design it at a resolution of 1024×1024 (just a nice number), but if you are using it as a favicon, it used to be defined as 16×16 and you’re going to be downloading something which goes there (on the tabs of your web browser) in any case, and unless you are doing something which will be displayed everywhere else at a higher resolution you don’t want to have a big file which will take 4000 times longer to download.

So it can be a bit of a balancing act.

I am thinking maybe tomorrow I’ll talk about why you might want to hand code your site, specifically around stuff like speed of loading, and server load.

This entry was posted in 30 Days and tagged , , , , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.