Category Archives: Accessibility

Metadata, Meta Tags, Meta What?

There would appear to be a certain amount of confusion about the terms "metadata" and "meta tags" – I know that it has confused me in the past so I am hoping that this article may make things a little more clear for those who are struggling with these meta-things.


As this article is being written for a newsletter focusing on accessibility, let’s start by looking at meta-things in this context. Checkpoint 13.2 of WCAG10[1] tells us to:

Provide metadata to add semantic information to pages and sites.

 What does this mean? Let’s start by defining what we mean by metadata: metdata is data about data. So, providing metadata for our page (which is data) means that by some means we need to describe that data.

How much metadata do we need to provide about our page to satisfy Checkpoint 13.2?  There is probably no one correct answer to this other than to provide as much useful metadata as possible.  The minimum is to provide a value for (X)HTML’s only real metadata element – the <title></title>.

Yes, the <title></title> is metadata – it is data that describes the data that is our page or document.  Please note that "Untitled" is not a good value for our <title></title>, nor is it cool or clever to use the title of the site for the <title></title> of every page in the site.  (Including the site title, however, is good as it allows the page to make more sense when viewed on its own.)

Meta Tags or Meta Elements 

What about  "meta tags" or "meta elements" then?  Are these not metadata?  No; meta elements (or tags if you will) are not metadata in themselves, they are (X)HTML elements that allow us to embed metadata in a page.

Let’s look at how we can use meta elements to put metadata into a document, using a couple of well-known examples:

<title>My page</title>
<meta name="description" content="A page I wrote about some stuff." />
<meta name="keywords" content="Smiffy, stuff, things," />

In the example above, we are presenting three pieces of metadata – the page title, some information called "description" and some information called "keywords".  The description would give a brief summary of what the page is about and the keywords a comma separated list of terms relevant to the page.  Whilst description and keywords are often published, how much they actually get used is debateable.  There was a time when search engines might have taken note of these but from what I have been reading recently, they are largely ignored for the simple reason that much metadata of this type cannot be trusted.  The description and keywords metadata values may be of use if your organisation has an in-house search engine that can make use of them – but there are better things available as we will see shortly.

I have seen many other terms added as metadata, for instance "author".  Great – it’s good to identify the author of a document, but information embedded in meta elements is really for machines to read, not humans.  Besides, can we agree that the creator or writer of a document is called an author?  Probably not.  

The problem that we have here is that we are not working to a formal metadata scheme.  If we make up our own terms, they will probably only be of use to us, and only then if we have our in-house search engine as mentioned earlier.

Formal Metadata Schemes

If we really want to make our metadata useful, we need to agree on what the terms are (description and keywords may be common, but they are informal).  If we all say that the person who creates a document is a "creator", then my in-house search engine can look at your documents and know who wrote them because we have both used the same term – and your in-house search engine can look at my documents and make sense of them in the same way.

Where we can get really clever is when I use a set of terms that you may not be familiar with, but I also provide you with a link to something called a schema that defines those terms.  Your software can then run off and look at the schema and come back and tell you what my metadata means.  This is where we start to touch on what is known as the Semantic Web.

Dublin Core: A Formal Metadata Scheme

Let’s look now at a metadata scheme called Dublin Core[2].  Some people might even call Dublin Core the formal metadata scheme as it is actually listed with the International Standards Organisation as ISO15836.  There are two parts to Dublin Core, the 15 Elements which constitute ISO15836 and the Terms, which give us much more scope about what we can describe.  It should be noted that Dublin Core metadata isn’t just about describing Web content – it can describe physical objects, events, services and more.

Rather than go into the boring theory of Dublin Core metadata, let’s get our hands dirty and look at a practical example; this is a selection of the Dublin Core metadata used to describe the document you are currently reading:

<link rel="schema.DC" href="" />
<link rel="schema.DCTERMS" href="" />
<meta name="DC.language" scheme="DCTERMS.RFC1766" content="en" />
<meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text" />
<meta name="DC.format" scheme="DCTERMS.IMT" content="text/html; charset=UTF-8" />
<meta name="DC.title" lang="en" content="Smiffy's Place: Metadata, Meta Tags, Meta What?" />
<meta name="DC.creator" content="Matthew Smith (Smiffy)" />
<meta name="DC.identifier" content="" />
<meta name="DCTERMS.license" content="" />
<meta name="DC.rights" content="(C) Copyright 2001-2007 Matthew Steven Smith" />
<meta name="DC.description" content="Article for the GAWDS newsletter clarifying the differences
	between metadata and meta tags and what the two are actually for." />
<meta name="DC.subject" content="Accessibility;Dublin Core;HTML;Technical;XHTML;adaptability;metadata;namespace;scheme" />
<meta name="DCTERMS.created" scheme="DCTERMS.W3CDTF" content="2007-08-14" />

Rather than describing every element, I will point out a few items of interest – you can read up on the elements and terms at the Dublin Core site[2].

Firstly, those first two links – what are they there for?  These links point to the schemas for the Dublin Core Elements (DC) and Terms (DCTERMS).  If you don’t understand my metadata, you can follow these links to the schemas so that you can find out how they work – or at least your software can.

The first meta element, DC.language, has more than the usual name and content properties – it also has a property called "scheme".  What this means is that the value of our content is part of a formal, controlled vocabulary.  This means that the only values that can appear in the content must be picked from this vocabulary, so we are all speaking the same language – no making up your own.

The element DC.title has yet another new property: lang="en".  This means that the title that I am presenting is in English.  I could have several different values of DC.title, each with a different language attribute, allowing me to present a multi-lingual version of the metadata.

Not forgetting that we started off talking about description and keywords, Dublin Core covers these.  Description is DC.description and keywords becomes DC.subject.  If you already have description and subject meta elements in your documents, you can easily convert them to the equivalent Dublin Core terms by a) renaming them and b) changing the commas in keywords to semicolons in DC.subject.  Easy!

I would encourage readers to go through the code example above in conjunction with the documentation on the Dublin Core site.

Who Uses Dublin Core?

If you decide to start using Dublin Core metadata in your documents, you will be in the company of libraries, museums, governments and educational establishments worldwide.  Contracts with many of these may mandate the use of Dublin Core metadata, so it is a good idea to be familiar with it.

Other Metadata in Meta Elements 

Other metadata that can be embedded in meta elements that are worthy of mention are:

  • The robots term with which we can tell well-behaved software user agents whether we want our pages indexed and links followed or no.
  • The meta http-equiv terms which allow us to tell our server software to embed their contents in the HTTP headers sent to the client.   Typically, these can include the character set being used (a duplication of our DC.format, if used) and expiry times for proxy/user agent cache control.

There are those who may contest that these last items are not metadata, as they do not so much describe the data (apart from the character set) as the disposition of the data – I thought I should include them though for completeness.

So All Metadata Lives in Meta Elements?

No. We have already seen that our only "pure" metadata field is actually the document <title></title>. Other than that, there is no reason at all that we have to put our metadata in Meta Elements.  Metadata may well be stored externally in another format, such as RDF.  We can then link to it:

<link rel="metadata" type="application/rdf+xml" href="my_ref_metadata.xml"
title="RDF Metadata" />

Metadata for Accessibility

A discussion about metadata for an accessibility-related newsletter would not be complete without a mention of EARL[3], the W3C’s Evaluation And Report Language, which we can use to describe the results of accessibility testing on our pages.  The Fundación Sidar’s HERA[4] software can generate EARL which we can then provide as accessibility metadata, linked from our documents as above.

Remember The Humans

Metadata embedded in (X)HTML <head></head> sections and stored elsewhere as RDF and other formats is all very well for software to read, but not much use to us humans.

If you have metadata that might be of use to your human visitors, such as the document creator, the creation date, license details, etc., put it in the document body, even if it duplicates the machine-readable metadata that you have already taken so much effort over.  Remember – as soon as your page gets printed, everything embedded gets lost.


  • Metadata is data describing data.
  • Meta tags or elements are a means of embedding metadata and other information in your (X)HTML document.
  • Metadata that does not conform to a published scheme may be of little or no use.
  • The most widespread formal metadata scheme is Dublin Core.
  • Metadata can be stored external to a document.
  • Present any metadata that may be of use to humans in a human-readable form in your document.




This article has been reproduced at

The Fate of Project Noddwr

Project Noddwr, which includes former work on the Tivis accessible touchscreen project has been shelved and the site taken down as of May 2007.

Project Noddwr was intended to be a repository of Open Source hardware and software components for independent living and also to encompass the scope of the Tivis project, originally designed for community/tourist information via touch-screens, and later to provide accessible kiosk solutions.

Examining the documentation that was online, I found it so out of date that I have simply removed it and created this page as a place-marker. Anyone seeking information on older content should contact me through the address at the end of this page or by my "real" e-mail address, should they know it. I still have a proposal available for the development of an accessible kiosk system; should anyone be looking to produce such a system and who may consider sponsoring this development, I would love to hear from them.

The spirit of Project Noddwr is not dead, just resting. I started the project early on in the stages of an ongoing illness, which has prevented me from pursuing the work that I had started. Of late, however, I have been working on the software component for my own use, to help manage time restricted by Chronic Fatigue and prop-up an impaired memory. Developments that would have found their way onto the Project Noddwr site will appear here, on Smiffy's Place.


2009-09-12: the domain was allowed to lapse at the end of last month and the domain which also pointed to this page will expire on the 8th of next month.  Whilst I will continue to offer related services to clients who might need them, as far as the Noddwr and Tivis projects are concerned:

"This parrot is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late parrot. It's a stiff. Bereft of life, it rests in peace. If you hadn't nailed it to the perch, it would be pushing up the daisies. It's rung down the curtain and joined the choir invisible. This is an ex-parrot."

(Substituting "project" for "parrot".)

New Version of Functional Accessibility Evaluator Released

The Disability Resources and Educational Services (DRES)
at the University of Illinois at Urbana-Champaign has released a new version of its online Web Accessibility Evaluation tool.

This is a rather neat bit of code that can be pointed at a site and will spider down to third-level links within the site, producing a report at the end.

You can access the Functional Accessibility Evaluator here. Please note that registration is required to make full use of this tool.

Accessible Tag Clouds


The example programmes presented here came about as the result of a thread on the GAWDS mailing list.

Example PHP Programme and Code Listing

The programme tagcloud.php demonstrates how (X)HTML ordered lists may be produced and styled visually as ‘Tag Clouds’ – where terms are presented in an arbitrary order and weight is given purely visually – and ‘Tag Wedges’ – where a logical sequence is used and weight is given by position in sequence. Tag Wedges may also be styled visually to provide further emphasis. To see how I made this work, have a look at the PHP code listing.

Real-World Example

In addition to the dummy data example described above, I have also created another example which is the same in all details other than the data being produced by an SQL query of the Smiffy’s Place database. Have a look at the categories
tag wedges and cloud
to see this real-world example.

And Finally…

To complement the real-world example and based on the same code, here it is again, in SVG. The reason that I have done this SVG rendering is that I feel that if we are ever going to produce an accessible, semantic, graph to do the job of a tag wedge/cloud, this will probably be the means to do it. (Please note – this is my first ever brush with SVG, so it is not pretty.)
UPDATE: I have now fiddled some more with the SVG so that it
looks a little better. Between Firefox and Opera, Opera
gives a much better rendering.

Please leave any comments on this topic against this post.

Saying "Whoops", Nicely

A Tragedy of Errors

In the early days of the Web when most content consisted of static HTML
pages, the type of errors that we encountered were generally
HTTP status codes, most famously "404 – Not Found". Web servers today still use the same status codes (HTTP has changed little) and – out of the box – produce error pages that are less than helpful to the average, human, visitor.

Whilst these status pages (not all the codes are indicative of an actualy error) might be less than helpful for us humans, the
status codes contain important information which can be used by
software user agents such as search engines. Indeed, the user
agents with which us humans usually interact – Web browsers –
could be coded to respond to HTTP status codes in a more
informative way.

There is something far worse than a terse "500 – Software Error" – receiving an error message with a status code of 200, which implies that the page has been found and is OK but merely says "Could not connect to database". With the increasing use of the PHP language, which tries its utmost to send HTML content, sloppy programming is liable to give rise to errors – often meaningless to the site visitor – being served as good pages.[1]

To make our sites more accessible and usable, we need a nicer
way of saying "whoops!"

Catching Errors, And What To Do With Them

Before dynamic content (that generated by software rather than
static HTML pages) is released to the public, it is hoped that
a certain amount of testing will be done to make sure that it
works. This testing, however, often fails to address runtime
errors which may occur when something breaks in operation – most
often a database connection.

As developers, showing a database connect error can be very useful.
The general public, however, is not interested; all it knows is
that the site at which it is looking is broken. Worse still, I
have seen error messages on sites that reveal far too much about
the inner workings of the software, possibly exposing
vulnerabilities to any visiting villains.

How should we address this? I would suggest that we should take
the following steps:

  • Ensure that anything that can throw an error is tested when
    called and an error-handling routine called if the test fails.
  • Provide a means by which we can easily switch our software in
    and out of debug mode. (A variable at the top of the programme
    along the lines of $debug=TRUE is a good way.)
  • Error handling routines should look at whether debug mode is onor not and either serve an informative error page for the
    developer, or pass an appropriate HTTP status code to the user.

Making "Whoops!" More Helpful

Those who only write static Web content and who fell asleep in the last section can wake up now – this part is relevant to you.

In the previous section, I explained how we can work around the
recent problem of software presenting errors as not errors, taking us back to our original issue of HTTP status codes and how they can be less than helpful to the general public. Let us now have a look at how we can make those codes work for us, inform our visitors and make our sites more accessible.

Know Your Web Server

Even if we are not involved in programming, some knowledge of how the Web server on which our content is hosted is configured can be important. As an inveterate user of the
Apache HTTPD server
software, the examples I present here will refer to that software.
Those using other Web servers, read the documentation or use
Google to search for specifics.

The Apache HTTPD allows us to specify our own pages, programmes or
scripts to handle errors, using the ErrorDocument directive. The
following example will direct 404 (not found) errors to Google. This is
not a helpful thing to do and is given for illustration only.

ErrorDocument 404

Custom error pages can be a good way to make our sites more
accessible when things go wrong.

Custom Error Pages

Now that we know that we can tell our Web server to call a custom page
when we get an error, what should we actually do? If we are serving
static HTML, we can provide informative pages suggesting what the
visitor might want to do next – whom they can contact for further
information or how to search for what they want. (A Google site search
form could be incorporated into a static 404 error document, for example.)

For those of us writing dynamic content, custom error pages are
where we can really start to make things happen. We do not need to write
a separate programme/script for every possible error – we can just use
one and feed the error code through the query string:

ErrorDocument 404 /errors.php?e=404
ErrorDocument 500 /errors.php?e=500

Here are a few things that we might consider doing with an error
handling programme:

  • When handling a 404 error, look at the requested URI and suggest
    possible alternatives.
  • When handling a 404 error, suggest that the visitor might like
    to visit a site map or site search facility.
  • When handling a 404 error, examine the requested URI for
    patterns that might suggest an XSS
    attack and warn somebody.
  • If we cannot connect to a database, send a 500 error page, but
    tell the visitor that the site is temporarily unavailable (do not say
    why – it can look bad), and provide contact information should they
    need something urgently. At the same time, send an e-mail and/or
    an SMS, using an online
    provider, to the site administrator rather than relying on a visitor
    to report the problem. The same could apply to any other failure of
    an external service upon which our site relies. If we are acting
    on the failure of an external service such as a database connection
    we must not make any calls to that service from our error handling
    programme! Error handlers must be able to stand-alone.

A Final Word on 404s

A frequent cause of 404 errors (and thus having to handle them) is the removal of pages, or conversions to different URI schemes. In the words of Sir Tim Berners-Lee,
Cool URIs don’t change.

If pages must be moved or removed, be certain to set up rewrites/redirects (another reason we should Know Our Web Server)
so that the visitor, at the very least, is directed to a page explaining
where a document has gone and why. It is suggested that readers acquaint
themselves with the HTTP status codes referenced at the beginning of this
article, in particular with the ones beginning with the digit 3.


By whatever means we are serving our content, let us ensure that when things go wrong, we provide information that is helpful to the site visitor – not to developers or hackers.

Smiffy, as always, is available to consult for those who
require help in saying "whoops", nicely.


  1. In my early days of writing Web applications, I used Perl (and still do when PHP is not specified). Whilst PHP will send content even when there is something fairly major wrong, errors in Perl coding often as not break completely, causing the server to send a 500 status code – a fairly obvious sign that something is broken. I am not criticising PHP, merely pointing out that it requires a little more care to code.
  2. If using debug mode in a visual environment, it is a good idea to have some code that writes "Debug Mode" in large letters at the top of each page to make it harder to forget to turn it off before deployment, which can make one look rather silly. Calling debug mode from the query string is another option, although there may be certain security implications.

Good English, Poor Accessibility?

Accessibility by Numbers

Whilst those of us who care about Web Accessibility tend to take care to make our own content as accessible as possible, there are times when we discover that we may not have been doing things as well as we could.

Over the last couple of weeks, I have been thinking about how we represent numbers in text. I was taught in school that any cardinal number (the ones we count with) less than 100 should be written out in full, for instance, one, two, three, forty-two. I can’t remember what we were supposed to do with ordinal numbers and fractions. I probably wasn’t listening at the time. ("Smith Minor does not pay attention in class.")

If we look at Checkpoint 14.1 of the WCAG10, we are told that we should "Use the clearest and simplest language appropriate for a site’s content". If our audience is not very good at reading English, the clearest and simplest way to represent a number must be in numeric form – 42 rather than forty-two or, even worse, two score and two. This could be even worse in French, where the humble 99 becomes quatre-vingt-dix-neuf.

I would say, therefore, that we should probably be writing our numbers as numbers, not words. For me, this is merely a case of breaking a quarter-century habit, and then getting detention for it.

Formatting Numbers

Consider the number 123,456 – what number is it? There are two correct answers that I know of, depending on one’s cultural background. Most of the English speaking world would say 123456 (one hundred and twenty three thousand four hundred and fifty six). In continental Europe, however, this number would signify 123 and 456 thousandths (one hundred and twenty three decimal four five six). Diversity may be all very well, but does the world really need two reversed sets of thousands and decimal separators?

Here lies another accessibility issue, both for humans and software agents that are trying to make sense of numbers. Every good document on the Web declares its language, but can that language be implied to be a locale as well? In software terms, it is locale, not language, that tends to define how we treat punctuation when parsing a number.

I really cannot see an answer to this, so I present a couple of my own tongue-in-cheek possibilities and one a little more practical, though imperfect. These suggestions will probably come back to me with a lot of red ink on them and a stern injunction to "See Me"

Smiffy Solves the Numbers Problem

  • All data must be typed, as it is in the better classes of programming languages with the exception of Perl (Perl is just too cool to warrant cluttering beautiful code with type definitions.) For example, the phrase "I sat there for 3 hours" should be expressed as "I sat there for <integer>3</integer> hours." – any separators found must be thousands separators and may be ignored as formatting, as an integer does not need a decimal separator. When declaring a float value, at least one decimal place must be specified: <float>234,567.0</float>. The decimal separator may then be deduced from the right-most piece of punctuation; anything else is just formatting.
  • Return to our numeric roots. If we are using Arabic numerals, surely we should be using Arabic numeric punctuation. The Arabic decimal separator looks suspiciously like a comma. Uh-oh, does that mean that the Europeans have got it right? Not entirely, as the Arabic thousands separator looks like a single right quote that has slipped down the page – not a full stop (period). So, all we need to do is to mark up our numbers with &#x066b and &#x066c, and we’re laughing. And we are all using Unicode now, aren’t we children?
  • Use full language plus dialect (like en-GB) to imply locale, and work from that. This all falls apart for those of us with our own custom locales: en-US keyboard, en-GB spellcheck, en-AU currency and ISO8601 times and dates. Can three, sorry, 3 uses of ‘en’ be guaranteed to imply a specific set of numeric separators? Not with 100% confidence.

If anyone has a real solution to the way that we present and interpret numbers, please do tell.

Dublin Core for Drupal

Whilst I had contemplated documenting my attempts at creating a Dublin Core metadata module for the Drupal CMS at Smiffy's Place, all such content will now live at my new Dublin Core for Drupal site.

This site is actually a Drupal installation (pretty much out of the box, as some may observe), which will also serve as the test-bed for the new module.

Those interested in keeping up with developments should subscribe to the front-page RSS feed.

Web Accessibility – A Small Part of a Jigsaw

Where does Accessibility start, and where does it end? For most,Accessibility is about creating Web content that can be accessed universally, with reference to whatever version of the WorldWide Web Consortium's Web Content Accessibility Guidelines.

Even for Web Accessibility, things do not end there. The Web Content Accessibility Guidelines (WCAG) are part of a process that also includes the Authoring Tool Accessibility Guidelines (ATAG) and the User Agent Accessibility Guidelines (UAAG).

The ATAG has a two-fold purpose: "…to assist developers in designing authoring tools that produce accessible Web content and to assist developers in creating an accessible authoring interface."

The UAAG "…provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities…".

So, not only do we have pathways for creating accessible content, but also for having an accessible means of creating that accessible content and of rendering that content. Developers of Web content would do well to familiarise themselves with ATAG and UAAG, as these can both impact on what happens to their content, and how it comes into being in the first place. (Badly coded user agents and authoring tools are NOT, in the authors view, an excuse for producing bad content.)

This is, however, still only a small part of a jigsaw. accessibility does not stop here. Close your user agent (browser) and your authoring tool – be it a sophisticated Content Management System or a lowly text editor. What are you left with? The computer's operating system. And just how accessible is that?

Those who have spent considerable time testing and repairing the accessibility of their content, should open their minds and apply a similar process to the operating system as a whole. Just how accessible is it? Does it make unexpected sounds and movement that might confuse? Can it be operated with a keyboard or pointing device alone?

Also have a look at other applications on your computer. How intuitive and accessible are they? Would they, if presented as Web content, pass the test?

Then move a little further back (literally). Look at the computer itself, the positioning and ergonomics of the display, keyboard and locator. Are these as fully accessible as they could be for you? Or for another person?

The further away from which we look, the more we can see of the jigsaw puzzle that is accessibility. It neither starts nor ends with Web content, but Web content is nevertheless a crucial piece, without which, the puzzle would be incomplete.

Now that we have seen the shape of the puzzle (and looked at the picture on the lid of the box), we should be better placed to fit in our little piece of Web Accessibility – in the right place and the right way around.

SmiffyCMS Toolkit, the software behind Smiffy’s place, is part of a development process to produce an accessible CMS/blogging application.

Whilst and Smiffy’s Place will continue to be the development area for this software, I am assembling the SmiffyCMS Toolkit, a set of PHP modules based on the best of and the most flexible parts of

SmiffyCMS Toolkit will be released under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 license. The Toolkit will not be an easy-to-implement CMS solution like Drupal, but will form the means by which bespoke CMS systems may be produced, without having to work from first principles. Documentation will be limited to code comments as I will be selling the creation of bespoke CMS solutions, based on the toolkit, as a service.


This is a list of some of the features that SmiffyCMS Toolkit will inherit from

  • The Slvg Lookup concept for handling redirect URIs and looking after obsolete URIs from legacy content.
  • Inclusion of fields in main page record for Dublin Core metadata.
  • Inclusion of a field in the main page for the URI of
    an audio equivalent of the content. This would be rendered
    both as <link rel="alternate"/> in the page
    header and as a link with optional icon in the page body. (None of this would appear if the URI were left blank.)
  • Automatic creation of a Google sitemap on page creation (can be over-ridden by the author).
  • When page categories are implemented (as with blogs), default metadata may be assigned to categories, which will be added to the dc.subject field, when the page is displayed. These will also be added to the list of categories for a page in an RSS2.0 feed.
  • Automatic creation of RSS (2.0) and RDF (RSS 1.0) feeds for categories and data ranges (mostly of interest for blogs, news and more dynamic pages).
  • Ability to integrate PHP CGI applications into the page template. (They would be run under the main programme, the functions being pulled in from an include file.) These would not be modules – remember, this is a toolkit; they would form
    part of the bespoke application.
  • Integrated RSS aggregation – create pages from feeds. (This was planned for Smiffy’s Place but has not happened as yet.)


SmiffyCMS Toolkit should be available in some shape or form early in the second quarter of 2007.