Stories from my Life as a Technologist
Presented at the Amigos Library Services’ HTML5 & CSS3 Online Conference a couple of weeks ago. It was recorded, but the recordings are not public, so instead, I’ve included my deck and a slightly edited version of the script that I used.
Continue reading “Making the Website More Accessible with HTML5 & CSS3”
Libraries hate library users. If we didn’t, our websites wouldn’t suck.
How to track in-page events. Decide which events to track, push to Google.
Single unified index for all the items from all libraries’ collections.
Yes! Also, slides/presentation.
As a web developer, I cringe at deprecated code and try my best to keep up to date, which right now means familiarizing myself with HTML5 and CSS3. In reflecting on how best to update our website, I realized that with a CMS, naturally some things are out of my control.
Whether it’s the core or plugins, users of a CMS are reliant on its developers to keep things up to date. Is that lost of control worth the benefits? Generally, I would say yes, but that doesn’t stop me from wishing that the technology that we use to adopt new specifications.
I think it’s interesting that in HTML5 there is now the figure and figcaption elements. If they are taken advantage of, I think it definitely helps to parse information in a webpage and to identify text that is directly related to images.
One thing that does bother me about WordPress (which actually has noting to do with HTML5) is that it forces users to have a title, and leaves alt text blank by default. I don’t know what the best solution may be, but I would propose to insert the title text into the alt text by default and then allowing the user to change it. If they want to leave it blank, then there should be a checkbox to mark it “intentionally left blank” or something. Perhaps this could be an admin option, but I would definitely want something like that since I would really like to force our users to have alt text, but I don’t want to touch the WP core obviously.
It’s a bit of a minor thing and while some may argue the usefulness of the different semantic tags, users of the rich text editor would have no notion that they’re using <strong> instead of <b> or <em> instead of <i>. While I admit that even I struggle on the appropriate use of each (I have to look it up every time I think about it), if we want to see widespread adoption, then we need to get users to think about their writing and what they intend to do when using any of strong, em, b, i.
While we avoid tables and it should never be used for layouts, users will still want to insert tables to display data without resorting to an image. I’ve always wondered that WordPress doesn’t have a table insertion button even under the kitchen sink. What worries me is that then users who have a basic knowledge of HTML will insert it themselves using the HTML view with improperly formed code.
You might wonder why I’d lump the two, and that’s because, other than (using the default) comment form, both of these are dependent on a WordPress setup.
Forms will generally depend on the plugin. Similarly, whether the layout is in HTML5 is very dependent on the theme, along with many elements of accessibility.
Unfortunately, while HTML5 themes are relatively easy to find, most form plugins do not tell you whether they are using HTML5 or how much of it.
I do realize that while there are a number of advantages to HTML5, especially in terms of structure, it’s still in development. Working in an educational institution, it’s also more work and sometimes difficult in some cases to ensure backwards compatibility.
In particular, screen readers do not necessarily support all the new HTML5 elements and will frequently ignore whole chunks of text or have difficulty with reading links, etc. Even the newest versions of screen readers do not necessarily recognize elements and properties designed to make webpages easier for screen readers to interpret.
I would like to think that since WordPress talks about trying to be accessible that anything in the WordPress core will be updated once there is widespread adoption not only among browsers, but also screen readers. Obviously, adoption will take time though. For example, many form input types have been adopted by most browsers, but has not been adopted by IE at all (will be in IE10).
One can only hope that adoption will pick up once various part of the HTML5 specifications are ‘cemented.’
I don’t normally do book reviews, but Jon Duckett’s HTML & CSS book was brought to my attention via twitter and it looked interesting, so I thought I’d give it a read.
If you’re the type that was discouraged from learning basic web programming because of the manual-like books, then I would definitely recommend this book. The information is presented in very visual ways and while there are a few pages here and there that have nothing but code on them (for full examples), almost every page has an image of some sort, whether as explanation or for decorative purposes.
While there are a couple of concepts I wish were explained in a little more detail with visuals (such as CSS selectors), I appreciate that Duckett will discuss deprecated tags and elements, which are still commonly seen, and point out which browsers do not support certain properties.
He also provides lists of practical websites or tools to use including commercial and open source alternatives. Code and extras can be found on the website, which can be useful even for those who never crack open the physical book.
It’s what it purports to be. So, I highly recommend it for beginners and maybe even those that want an easy to digest review (it’s very easy to skip sections you feel you already know).