There are a number of things you need to consider when you’re considering your son’s primary education, because you know it’s important (it’s one more thing that as a parent, you have the opportunity to fret about).

Obviously, you want your child to go to a modern school.

Secondly, you need to consider what schools are in your catchment area, as you will stand a better chance of getting your children into one of these. You also need to consider things like siblings: if a child already has a sibling in a school, they are given higher priority than one in equal circumstances without a sibling in that school (at least, that’s how it works in our area).

What we certainly don’t want to happen is for one child to get into one school, and then the second child not be able to get into that school. So our preference will be for a school where we’re already in the catchment area.

But then how do we decide? That gives us the choice of a Church of England school or a “standard” school, both of which rank ahead of the area’s average, and the nation’s average, for educational achievement, so both have good reputations.

So how do you make that decision?

Well, I’d suppose you’d want your child to go to a forward-thinking school, where they would treat everyone equally, regardless of their ethnic background, whether or not they are disabled, irrespective of the marital status and/or sexual orientation of their parents, and where, basically, girls and boys are treated equally, rather than some being shoved through some kind of metaphorical ‘back door’.

You want a school that treats pupils fairly, and instils in them respect for the world around them, respect for other cultures, and teaches them about religious belief, but not in such a way that they don’t feel able to question it.

You want a school, in other words that will give your children the tools to — respectfully, of course — take on the world. So how do you decide which of the two in the catchment area is the most appropriate?

Well, what else is there available that you could possibly consider. Have you looked at the facilities available to the school?

Do you consider which of the two schools has the most modern facilities, and is best suited to your child’s education? To some extent this amounts simply to saying “which school has the most money”. Is that really a fair way to arrive at that sort of decision?

But then again, am I prepared to be “fair” with my children’s education? Or am I more likely to fight as best I can to ensure that they get the best education possible, whether that’s “fair” or not?

And after all, it’s not only the facilities of the buildings themselves, that needs to be consider, it’s the teaching methods as well.

Do the schools offer a computing suite? Do they have internet access (and how is it monitored?) Are children encouraged to experiment to find out the answers to a solution, or does the school prefer more traditional, rote-learning methods?

And then of course there is the curriculum: schools have guidance as to what to teach the children within certain parameters, but it can obviously be approached in different ways, and one school may focus on some areas of the curriculum that another finds less important.

There may well only be small variations between one school and another (particularly when those schools are close to each other) but if you remember that in general — particularly once he/she’s been there a few years — what the school deems important, or appropriate in approach, will tend to mirror what the Head thinks.

You need to consider the approach to education taken by the school: what do they want your child to learn? Are those the same things that you consider important?

Schools may also consider teaching things which aren’t directly part of the curriculum, if they feel it fits in: can you help a child learn more about their place in the world through looking at the history of their region, through the history of education, or through some other context?

So what you do is you pick up a prospectus from each school and you compare them against one another. You discover that the schools have something approaching the same facilities, the same teaching methods, and that while one has scored consistently slightly higher on educational achievement at age 11, both are scoring very well indeed, and as you know personally, going to a below average school doesn’t necessarily hold you back anyway.

Is there anything else to consider?

Yes. Do the schools encourage sporting activity?

Do the schools have access to playing fields? Do they encourage children to take part in solitary games, team games and so on? Do they have access to decently trained staff? Do they actually have proper sporting equipment? Although that’s probably not one to worry about: I’d imagine both schools are relatively well organised so it’s not like they’d be sending the kids out with a hoop and a stick, is it…

So, you’ve had all of these different things to consider, how do you finally decide how to narrow down your child’s first choice school on the application form (bearing in mind that the other school is going down as the second choice, anyway)?

Well, firstly, you eliminate the recreation of a school from 1913 that you’ve used as the basis for all of the photographs (all photographs taken of the school in the Colliery Village area of the open-air Beamish Museum in County Durham — well worth a look if you’re ever in the vicinity), and you just consider the schools that your child is actually in the catchment area for.

Yes, if you ignore the photography, this actually is a serious article…

But then what?

Well, you weigh up all of the factors you’ve already considered, and when the result — as it has done here — has come out fairly close between two schools, you add in one final factor. Which one your son would rather go to.

As it happens, BTP’s request was to go to the school that my wife and myself slightly favoured ahead of the other one anyway, but I like to think that — assuming that there wasn’t a significant difference between the two — we’d always consider his opinion important in making a decision like this.

After all, he will be the one who goes there…

Nothing.

What I do have is considerable experience and knowledge in the field of accessibility, and considerable experience and knowledge of working in the public sector in the UK, having not only worked for my public sector employer, but also having discussed common accessibility issues with other public (and private) sector webbies from around the world.

I’m not claiming this lot of guidelines is going to be perfect: I’ll state right now that they aren’t. They are intended to be a bodge job: something practical, achievable and where possible measurable that will bring benefit to users with disabilities. They are intended to be suitable for the UK Public Sector as a whole, whom I don’t expect to have a great deal of specific knowledge about accessibility.

They are also intended to be a first draft, to be kicked around and updated by other people taking part in the PSWMG as I proposed earlier, so I’m expecting that they will evolve, not to become the perfect set of accessibility guidelines, but to become more appropriate to the UK public sector. That’s all I’m pitching them at.

Right. That’s the why, now let’s get down to the what.

The Reasoning Behind The Guidelines

The guidelines are a mix of stuff from WCAG versions 1 and 2, with a couple of my own ideas thrown in too. One of the key things about these guidelines is that I would expect them to be regularly reviewed and either re-approved or revised by the PSWMG to avoid the farcical situation we have now where WCAG 1.0 is the set of officially sanctioned guidelines that we are expected to adhere to but they are somewhat dated, and sites are being told that because they fail the mandatory guidelines, they are inaccessible, simply for using a deprecated attribute such as valign which, while not being good practice, is not going to suddenly mean that someone with a disability can’t use the site.

I’m proposing to stick with three accessibility ‘levels’, with a similar plan to what there is now, except that I’m simply going to call the levels ‘Critical’, ‘Important’ and ‘Desirable’. Obviously the target is for everyone to be able to achieve all of the ‘Critical’ and ‘Important’ levels. I’m focusing primarily on ‘what affects users with disabilities’. Stuff that is good practice but won’t directly affect users with disabilities may be found in the ‘Desirable’ category.

I don’t expect everyone to agree with my selections. I don’t expect everyone to agree with the importance I’ve associated with them. That’s why I said that this was a first draft, and why I’m proposing that the other members of the PSWMG kick around with it and that between us we arrive at a set of standards we can all endorse.

The other thing (and this may be controversial, but I’m trying to strike a balance between the people who reject accessibility because they perceive it as difficult or onerous, and the people they perceive as accessibility zealots) is that I have deliberately reduced the number of criteria. WCAG 1 has 65 ‘checkpoints’. WCAG 2 has 56 ‘success criteria’. I want to deliberately reduce that number further, so to simplify things I have tried to stick to 15 checkpoints at each level, or 45 in total.

Critical Guidelines

1. Provide a text equivalent for every non-text element (null if decorative); note that an equivalent to a visual CAPTCHA would be an audio CAPTCHA
2. Ensure that all information conveyed with colour is also available without colour
3. For data tables, identify row and column headers
4. Ensure that pages are usable when scripting and other programmatic objects are unavailable or that the scripting/programmatic objects used work with assistive technologies
5. Do not cause pop-ups or other windows to appear, and do not change the current window except when initiated by the user
6. Clearly identify the target of each link from the link with surrounding context
7. Associate labels explicitly with their controls
8. Ensure that text (and images of text) have a luminosity contrast ratio of at least 5:1 (or 3:1 if larger than 14 point)
9. Ensure that text size can be adjusted up or down two size increments (approximately 50% up and 40% down) without loss of content or functionality
10. Ensure that if the sequence in which information is presented affects the meaning (e.g. in a series of instructions), that the correct reading sequence can be programmatically determined and that keyboard/tab navigation is consistent with that sequence
11. Audio description of video, or a full text alternative for multimedia, is provided for pre-recorded multimedia
12. For any time-based multimedia presentation (e.g. a movie or animation), syncronize equivalent alternatives (e.g. captions or audio description) with the presentation
13. Captions are provided for pre-recorded multimedia except where that multimedia is itself provided as an alternative to text
14. All functionality of the content is operable through a keyboard
15. Content does not contain anything that flashes more than three times in any one second period, or the flash is below the general and red flash thresholds

Important Guidelines

1. Information and relationships conveyed through presentation can be programmatically determined through the correct use of appropriate elements (e.g. headings and list markup used correctly)
2. Navigation mechanisms are used in a consistent manner
3. More than one way is available to locate content (i.e. more than one of site map, search page, table of contents, in-page links, navigation mechanisms)
4. Do not use tables for layout unless the table makes sense when linearized
5. Identify the primary natural language of the document
6. If any audio plays for more than 3 seconds, provide a mechanism to pause or switch off the audio
7. Any audio content that contains foreground speech does not contain background sounds that make it difficult to hear the foreground speech
8. Web pages have meaningful titles
9. A mechanism (glossary, in-page definition or link to an explanation) is available for identifying specific definitions of words or phrases that are used in an unusual or restricted way, including idioms and jargon
10. The clearest and simplest language appropriate to the content is used (reading ability required should be no more than that expected for age 14)
11. For forms that cause transactions to occur, either the transactions must be reversible or the user must be presented with the details to check and confirm before the transaction takes place
12. If an input error is detected, the item in error is identified and described to the user along with suggestions for correction if known and appropriate (e.g. “this field should be numeric” is fine; “the password for this user is actually ’9Shearer9′” is not)
13. A mechanism is available to bypass blocks of content that are repeated on multiple web pages (e.g. allow headers and navigation sections to be skipped)
14. A mechanism for finding the expanded form of abbreviations (including acronyms and initialisms) is available — by use of the appropriate element with title, by an inline expansion, by a link to a glossary etc.
15. Documents made available in PDF format must either also be available in a text format (HTML or plain text) or must be tagged and structured so that they are accessible to users of assistive technology

Desirable Guidelines

1. Identify changes in the natural language of a document’s text
2. Ensure that pages are usable when scripting and other programmatic objects are unavailable (strengthens guideline C4)
3. Do not use tables for layout
4. Provide different types of searches for different skill levels and preferences
5. Create a style of presentation that is consistent across the site
6. Ensure that timing is not an essential part of the activity of the content, except for non-interactive multimedia, time-based testing or real-time events
7. Clearly identify the target of each link from the link alone (strengthens guideline C6)
8. Information about the user’s location within a set of web pages is available (e.g. via the navigation mechanisms or a breadcrumb trail)
9. Deprecated attributes or elements are not used
10. Pages validate to the specifications used
11. Documents can be read without style sheets
12. Text is not right-justified
13. Sign-language interpretation is provided for pre-recorded multimedia
14. Ensure that text (and images of text) have a luminosity contrast ratio of at least 7:1 — or 5:1 if larger than 14 point (strengthens guideline C8)
15. Text size can be adjusted to anywhere between 50% and 200% of the original size without loss of content or function, and up or down three size increments without requiring the user to scroll horizontally (strengthens guideline C9)

Comments

Comments are open but if you work in the UK public sector, I would rather you made comment on the appropriate discussion thread. The reason for this is that comments made there will be drawn together to help form a consensus of opinion from within the UK public sector on what accessibility standards they think they need. Comments made here will be noted by me, but won’t be used officially for this purpose.

Also, please remember that if you want to offer the sort of criticism that just tells me that these guidelines are rubbish, or that I am rubbish (or variations on that theme), I won’t bother listening to you. If you want to offer constructive comments that tell me how I can improve these guidelines so that they are more applicable to the UK public sector, then I’ll be very willing to listen.

Nevertheless, for some reason I’ve got caught up in the whole Jack The Ripper genre, and have had a fascination with it since my early teens.

I’m certainly not condoning the wanton slaughter of prostitutes in Whitechapel or elsewhere: you only have to look at any of the books and see any of the police photographs of the victims to realise what gruesome atrocities were inflicted on these people, and that there can be no admiration for someone who could do that to another human being, let alone repeatedly.

So why am I fascinated by the Ripper then? I can hazard a few guesses:

• we have a name in common
• his (?) identity is still unknown after almost 120 years
• there are so many theories about who he was
• and the fact that he seems to have captured the public imagination makes him more interesting

But this isn’t going to be one of those posts where I talk about pop culture, how the media has changed over the last 100 years, about a “media frenzy” or anything like that. Nope, in this one I’m specifically going to be talking about the Jack the Ripper murders and discussing some of the theories (and books) relating to them (my niece is going to be doing a school thing about Jack the Ripper and digging out the books for her to borrow set me off on this one…).

So if it’s not your cup of tea — and I don’t blame you — then feel free not to read on.

Just the facts, ma’am

Canonically, there are five murders associated with Jack the Ripper:

1. 31 August 1888 — Mary Ann Nichols
2. 8 September 1888 — Annie Chapman
3. 30 September 1888 — Elizabeth Stride (‘Long Liz’)
4. 30 September 1888 — Catherine Eddowes
5. 8 November 1888 — Mary Jane Kelly

Depending on which sources you read, some earlier and some later murders are also ascribed to the same person, and some people doubt whether all five of these were committed by the same person, but these are traditionally the murders associated with ‘Saucy Jack’.

Everyone Knows Who It Was

Or at least, seemingly every writer who has written about Jack the Ripper has apparently managed to identify without doubt who the murderer actually was.

Of course, that could have something to do with the fact that if you’re trying to pitch your Ripper book to a publisher, and you’re describing the meticulous detail you’ve gone through to get to see as much first hand evidence as possible, the publisher isn’t going to be interested in that. The publisher will want to know if you’ve found out anything new, because that is what sells.

Portrait of a Killer

The American crime novelist Patricia Cornwell, in her book ‘Portrait of a Killer: Jack The Ripper — Case Closed’ (and TV show) asserts that the Ripper was the painter Walter Sickert.

Patricia seems to have seen a couple of paintings by Walter Sickert (‘the Camden Town murder’ and ‘Jack the Ripper’s bedroom’) and to have decided that this point that Sickert was, definitively Jack the Ripper, and then to have spent the rest of her time trying to come up with evidence to support her theory.

I find it indicative of this book that Cornwell does not really appear to consider any other suspects seriously at any stage, and appears unwilling to find or discuss evidence which runs contrary to her theory — or simply to dismiss it. For example, contemporary letters from his family place Sickert in France at the time of the murders: Cornwell simply asserts that he could have travelled to London and back repeatedly.

Well, yes he could, but it’s also possible that it could have been someone else…

Then there’s the evidence she trumpets: the mitochondrial DNA evidence that ‘proves’ Sickert is the Ripper, which in fact does nothing of the sort. The mitochondrial DNA ‘match’ doesn’t give the millions-to-one chance you’d associate with modern DNA testing. Nope.

The chance of someone else having that same mitochondrial DNA sequence is about 100:1.

Nor is it a match from the crime scenes: she has managed to match Sickert’s DNA to two of the Ripper letters. There are still two more steps she ought to make before jumping from there to ‘Sickert was the Ripper’.

Firstly, it is believed that many (if not all) of the Ripper letters were hoaxes, and that they weren’t all written by the same person. Even if we could therefore establish that Sickert wrote one or more of the letters, we’d need to separately establish that he was the killer. This, to my mind, Cornwell does not do.

Secondly, the the mitochondrial DNA match would also have matched between 0.1% and 10% of the population, meaning that with a population of around 5.3 million, somewhere between five thousand and half a million other Londoners (people who presumably actually were in London at the time) would have matched that same DNA sequence.

That hardly seems ‘beyond reasonable doubt’.

The Last Victim

The book The Last Victim is purportedly about the wife of Jack The Ripper, who is claimed to be the Liverpool cotton merchant, James Maybrick, mostly on the evidence of James Maybrick’s diary which appeared in the 1990s and contained his confession to being Jack the Ripper.

The only slight problem with this otherwise reasonably reason for concluding that he may have been Jack the Ripper was that the fact that in 1995 Michael Barratt (married to the author of ‘The Last Victim’ at the time the diary was ‘discovered’) to swore an affadavit stating that the diary was a hoax, that he was the author and explaining how he’d done it. This was then retracted by his solicitor, and then re-affirmed again by Michael a couple of weeks later.

This was backed up by further tests suggesting the ink seemed modern, the handwriting didn’t match James Maybrick’s handwriting, and there were apparently textual anomalies that suggested that certain landmarks were not known by the names used in the diary in Maybrick’s time.

The question therefore appears to be not “did James Maybrick write the diary?” but “is it a modern or an older forgery?”

Uncle Jack

(Yes, a very different “Uncle Jack” to the one I mentioned yesterday!)

Tony Williams claims to be a direct descendant of Jack the Ripper, who he names as John Williams (also founder of the National Library of Wales).

A lot of the book is spent covering John’s early years, and his later years, somewhat detracting about what surely is the crux of the matter — the time he spend in London in 1888 and more particularly what he was doing there.

Tony does a reasonably convincing job of allowing us that John had the means (as a doctor, he had access to big sharp knives, after all), the motive (wanting to study the internal organs for reasons of research into obstetrics), and that he was around in London at the time and could conceivably have just about had enough time to theoretically able to commit the murders.

Again, even if we buy this theory to this point, this doesn’t prove that he was the murderer, merely that with only access to historical documents that have survived until the 21st Century, we are unable to prove that he wasn’t.

Furthermore the suggestion that the Ripper murders were committed ‘for anatomical research’ seems somewhat ludicrous in light of the somewhat excessive mutilation carried out — particularly the lacerations to Catherine Eddowes face and virtual dismemberment would suggest something a little more excessive than simply wanting to remove internal organs to enhance medical knowledge…

Another ripping yarn, which tells us more about the attitude of the medicinal profession to the poor of Victorian London than it does about the actual identity of Jack the Ripper.

A 21st Century Investigation

What I particularly enjoyed about the first edition of this book is that while Trevor Mariott used modern techniques to paint a general picture of Jack the Ripper, and he wasn’t afraid to go through the usual list of suspects, in most cases tearing the cases against them to shreds, he wasn’t afraid, at the end, to admit that he couldn’t name Jack the Ripper, although he thought he could tell several things about him — and that he suspected he was probably a merchant seaman

He also highlights four other murders in London (and a few elsewhere) which he examines for similarities to the Jack the Ripper M.O and states that he also believes Alice McKenzie (died July 1889) was also a victim. This rather begs the question of what Jack had been up to in the mean time, since he’d generally only gone a few weeks between killings before…

…but Marriott finds a newspaper report which suggests that six prostitutes were murdered in a similar fashion in Nicaragua in January 1889, and another in Flensburg in Germany in October 1889. He later wavers over te Nicaraguan ones, suggesting as the only report he can find is from the Times, he’s not sure whether the Whitechapel murders have somehow been mixed up and then reported back.

The people behind the Jack the Ripper casebook have located various contemporary press reports from the Americas which discuss the Nicaraguan murders, although they themselves do seem to have been compiled from a single original source, so while the ‘Managuan Ripper’ seems more likely, we’ve still not proved it conclusively.

But it is suggestive that Jack the Ripper may have been a merchant seaman, and Marriott does a good job (or as good a job as is possible, considering the records available) of comparing crew rosters and the like to try and narrow down the killer.

In the second paperback edition, he goes as far as to name him as Carl Feigenbaum. Carl (also known as Karl Zahn and Anton Zahn) was executed via the electric chair in 1896, after having been found guilty of the murder of Mrs Juliana Hoffman by cutting her throat from ear to ear with a long carving knife. However, there was no mutilation (although he was interrupted) and it was his landlady rather than a prostitute, so it’s not quite the same MO.

However, after the execution, his lawyer (Lawton) made some statements suggesting he may have been the Ripper:

Lawton also claimed that his client had confessed to him that “I have for years suffered from a singular disease which induces an all absorbing passion. This passion manifests itself in a desire to kill and mutilate every woman who falls my way. At such times I am unable to control myself.” Lawton claims that he was able to ascertain that Feigenbaum had been in Wisconsin during a series of murders there as well as being in London in 1888. When he asked the gardener about the Whitechapel murders he was said to have confessed that he had indeed been in London in the Autumn of 1888 but that “the Lord was responsible for his acts and that to Him only could he confess.”Casebook: Jack The Ripper

In addition to this, Trevor Marriott’s second edition book looks into the possibility that Feigenbaum may have murdered elsewhere in the U.S., again with a Ripper-like MO.

In short, he makes a pretty darn good case, if not for definitively fingering Feigenbaum as the Ripper, then at least of putting him near the top of our suspect list.

Kosminski, Kaminsky, Cohen, what did you say?

In fact, the only thing that stands between me and a belief that Marriott is right, is the fact that Sir Robert Anderson, one of those investigating the case, seemed fairly certain that the criminal had been identified:

“…he had been safely caged in an Asylum.” Criminals and Crime, 1907

“In saying that he was a Polish Jew I am merely stating a definitely ascertained fact.” (The Lighter Side of My Official Life, 1910)

…there was no doubt whatever as to the identity of the criminal…” (Police Encyclopedia, 1920)

Casebook: Jack the Ripper [2]

What is puzzling is exactly how sure he seems to be when no-one has been brought to justice.

The seemingly most likely candidate for this was the Polish Jew Aaron Kosminski, but apart from being a barber (so he would have a knife), once threatening his sister with it, and having been detained in a mental asylum where they were worried about his spiritual wellbeing because of his “monstrous acts” — in other words, he would masturbate — there seemed to be very little of the, well, frankly the homicidal tendencies that you’d want to associate with Jack the Ripper, meaning that he’s generally dismissed as a suspect.

Which leaves us with the bizarre situation where the police seem to believe it was him yet he would presumably have looked an unlikely suspect even at the time. Why could this be?

Well, one option that has been put forward was that the murderer was a different Polish Jew who was also detained in an asylum, leading to the confusion between the two. This would seem a little unlikely, if it wasn’t for the fact that David Cohen, who might have actually been called Nathan Kaminsky (David Cohen being a ‘default name’ for an unknown Jew, much like ‘John Doe’ is used today), was, like Kosminski, a Polish Jew who was incarcerated at Colney Hatch asylum.

Kaminsky, whose profession would have identified him as a candidate for the ‘Leather Apron’ suspect, apparently disappeared in 1888 after having been cured of syphillis (which might have given him a motive to hate prostitutes). Later on in the same year, an unknown Polish Jew, who becomes identified officially as ‘David Cohen’, is moved from the Infirmary to Colney Hatch asylum because he is seen as destructive, spiteful and with violent tendencies.

He was initially taken into custody in December 1888, and none of the murders usually associated with Jack the Ripper occurred after that date.

Make your mind up, who was it?

But there is also seemingly a good case for Feigenbaum. The question is not “was it Feigenbaum or Kaminsky?”; we have not yet definitively established that it was either. All we have done is to suggest the possibility and draw connections. It may have been one, or the other. It may have been neither.

I don’t know. If I had to bet on it, I’d probably put money on Marriott’s original theory of a merchant seaman (without definitively stating ‘Feigenbaum’). Both stories have a few tenuous links in their chains, but I think there are one or two more with the Kaminsky/Cohen one (even though I find that version more colourful), but the merchant seaman one (whether or not it was Feigenbaum) also accounts for other similar murders around the world in the same time period.

A number of the issues I raised about it before — issues of governance and the like — appear to have either been partly or wholly addressed and I’m confident that, assuming that they can get enough people willing to volunteer their time to take part, the group can be a success.

However, that may be one of the issues. For a start, the group pitches itself as being:

primarily aimed at web managers in the UK’s public sectorPSWMG

That is, it’s happy to include other people, but that’s not who it’s primarily for.

Well, as someone who isn’t a public sector web manager, that already makes me feel like a bit of an unwanted hanger-on. That’s not a problem to me: I only have a finite amount of spare time and if a particular group doesn’t want me to help them out, that’s fine by me.

I also know from private conversation with one of the people from PSF that at least one of the managers who has expressed an interest has volunteered an opinion that the group should be restricted to public sector web managers.

That’s not a problem for me, and I understand where he or she is coming from. After all, the managers are the ones with the “real-life” responsibility; they are the ones who will be held accountable in their day jobs for the decisions they make; they are the ones who will need to decide whether their council website is going to follow standards set out by the PSWMG, they have a need to be practical and they are concerned about a potential risk of the group being hijacked by some other group with a slightly different agenda (probably by people they would think of as ‘standards zealots’).

Believe me, I do understand that, which is why I don’t think I should be arguing about whether the PSWMG should be primarily for managers, or be a ‘broader church’. I think this is a decision for other people.

However, I do reserve the right not to want to dedicate my free time to a group where I’m treated as a second class citizen simply because I have different responsibilities in my day job.

When I turn up to work, part of the deal with being paid is that I accept the organisational hierarchy around me. I know who my managers are, and I know that while I can raise issues or suggestions to them, they are the ones with the overall responsibility and accountability and when it comes down to it, I’ll do what I’m asked to do.

But I can’t say I’d be willing to join a volunteer group where I’m asked to respect the same hierarchy, and don’t get either an equal say, or a say proportional to the amount of work I put in. If my thoughts, works and opinions aren’t at least equally valued, then I simply won’t do it.

I can still contribute to the group from outside by talking about it publicly, by making public suggestions on my website and so on, but I don’t really see the point in volunteering to be a small, unvalued and unacknowledged cog in a different organisation, when by making by points publicly I get — assuming that they are good points, anyway — to enhance my professional reputation as well as my personal ‘brand’.

And I suspect I’m not the only non-manager who thinks like this.

Which is why I have doubts that the group as it stands will achieve in all of its aims.

The group wants to do things like:

• Produce guidelines and white papers on subjects of interest, for example quality assurance and benchmarking
• Publication of formal reports, including an annual “state of the nation” evaluation of the public sector web
• The publication of performance reports, based on transparent, consensual criteria

PSWMG

I think those are all worthwhile objectives. I just don’t think that the majority of public sector web managers will (or should be expected to) have the technical expertise to evaluate and benchmark websites; to compile the consensual criteria to be used in the performance reports (although they should be involved in approving them) or to carry out benchmarking.

I also think it unlikely (although I’m prepared to be wrong on this one) that many public sector web managers would be willing to spend the time necessary to go through and evaluate web sites in this way. I’d presume this is something that they would expect to be done for them.

Which is really the crux of the problem. The way I see it is that the Public Sector Web Managers want to have the authority in the PSWMG, but they want the staff with the technical skills to do the donkey work. Well, no thank you. I’m quite happy to do work as instructed when I’m paid to recognise someone else’s authority, but if I’m giving up my spare time to do work then I damn well want the credit and acknowledgement for the work I’m doing.

So there are two conflicting problems:

• If the group is just about managers, the managers won’t get everything they want because the technical resources they need may not be available
• If the group includes everyone, then it may not head in a direction that the public sector web managers want

How do we solve them?

I don’t really know. It depends on what people want out of the group. The things I want are recognition for the work that I do and an influence proportional to that work, as opposed to being proportional to my day job.

If the managers want to get some un-named and unacknowledged ‘grunts’ to do this sort of work for them, then I don’t really know who’d be willing to give up their unpaid spare time to do under-appreciated work when they wouldn’t have any say in how that work was to be used.

One option would be to commission someone to do this work for them. The drawback with this is that it would of course cost money.

Of course, if the managers are happy that they will be able to contribute the time and experience to do this themselves, then there’s no problem…

Another alternate option is to beef up the ‘recognition’ side of things, and use something akin to the W3C‘s “Invited Expert” status.

It the PSWMG were to officially request advice or help from me, to help in devising testing methodologies, to help define standards, or to help in analysing sites, then I’d be more likely to give up some of my spare time to do it if the PSWMG formally and publicly requested my help as an expert in that field. It would be a boost to my personal standing, it would certainly make me feel valued, and it would be a way in which I’d be willing to contribute without expecting to be involved in the decision making if the group were publicly acknowledging that they considered my input to be valuable in this way, and/or that any work I was involved in would clearly indicate who I am and this status.

I would also expect to retain at least some form of shared rights over documentation or other products that was produced either by me or indirectly from work that I was asked to do.

In other words, I’ll work for one of three things, and I don’t honestly mind which one it is:

• I’ll work with others if I’ll be given an equal say in how things are going to work, because then I can help steer it to do what I think is best
• I’ll work for others and accept a hierarchy of importance if I’m being paid to do so
• I’ll work in exchange for a decent bit of public recognition, and retaining some form of rights over the work I carry out

If the PSWMG don’t want to give me any of these things, then I’m sure I’ll still stick my oar in from time to time on my site, telling them what I think they’re doing wrong as and when I see fit (and indeed where they are going right, if appropriate!), as I can still “work for the greater good” by doing this, but if they want to be able to ask me to carry out specific tasks, then it’s not unreasonable for me to expect one of the above in return.

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards; usability, code-cutting, and testing and go-live (this article).

Testing

There are various different sorts of testing: there’s unit testing (where the developer tests each bit as they’re developing it), system testing (where the tester/developer tests the system as a whole once it’s developed); user testing (where it’s passed over to the users for testing and they have a look at it) and finally, assuming it’s passed every other suite of tests thrown at it, user acceptance testing (where the users compare what the system does against what was initially agreed that it should do) and then they hopefully sign it off and start using it.

If you have a less formal structure, or the development team have a good working relationship with the user department, you can carry out iterative user testing from the very early stages of development.

You need to have a developer who doesn’t get upset if the user doesn’t like something he or she has done, and a user who understands that they are dealing with a system which is only partially developed and so is liable to collapse in a heap at any time, but assuming you can clear those hurdles then you can begin iterative user testing at an early stage which is immensely beneficial to projects.

Early User Testing: Screen Shots and Colour Schemes

You can start this right from the beginning of the development: produce some mock-up screen shots of the system, showing the navigation bars, the colour scheme and so on, and send them to the user for comment.

The earlier in system development you are, the easier it is to make changes to things like system colours: further down the line you may have added images because they particularly “go” with certain colours, meaning that you’d have to replace these too, but if at an early stage you’re told that your pink-and-red colour scheme isn’t really suitable, and something involving greens would be more in keeping with a system for tracking first aid, then it’s really no problem to make these changes.

Of course, it’s important to differentiate between internal and external systems here: externally-facing systems may well have to have the corporate branding on them, and the individual users may not have much say in the final ‘look’ of this system as it may be decided corporately, but for internal systems it is generally easier to adapt things to meet the user requirements.

Early User Testing: Demo Pages

If you have any sort of test environment which can be made accessible to the system’s end users, or it is possible to publish temporary copies of the application in a place the users can access, then once you have completed the function of a few pages or forms, you can pass this to the user for testing.

This is of immense benefit, because you will of course be following the usability principles I told you about earlier, so you’ll be planning to lay out similar screens (“add person”, “add function”, “add venue”) in a similar way, and have the functions work similarly. Which is why it is of immense benefit if someone asks you after you’ve only written one of them “couldn’t you do it this way instead?”. Of course you could, particularly when there is only one page you need to adjust instead of five!

Not only that, but this buy-in from the users makes the development much more of a two way process: they feel as though they are taking an active role in the development process (as in fact they are), meaning that they have more of an emotional investment in the project and are more keen to see it succeed.

I’m aware that that might sound like management-speak but that doesn’t mean it’s not true. If you ask for feedback, and show that you’re willing to listen to that feedback and act on it, people do feel more involved and – quite correctly – feel that they are an important part of the project.

These demo pages can them be revised and republished as often as necessary until you’re ready to sign-off the project and for it to go live.

Project Sign-off and Go-Live

There comes a time when the developers and users of any project are happy for the project to be signed off and the system to go live. If the development of the system has been managed well, then ideally the users and developers will be ready at the same time.

Depending on whether or not there are any external pressures to have the system live by a particular date, there may be some feeling that further iterative development and testing steps should be carried out and that the system should be refined further and further before go live.

It’s important to ensure that the end-users are getting a fully functional system that does what they require, but from the point of view of the development teams, it’s also important to consider that you’re using the law of diminishing returns by this stage (every individual tweak takes longer to carry out and has less impact on the user department).

Ask the users to compare the system against the Acceptance Criteria that were agreed earlier. Hopefully – unless you’ve agreed any revisions — the system will do what was agreed. If not, then the users will point out where the system falls down and you can look at fixing that.

If the users have identified any changes that they would like but aren’t necessary in order to meet the acceptance criteria, it is helpful if some development resource can be allocated to this — even if not enough to carry out every request, if each request is associated with a certain amount of development ‘time’, and the users are told that they have X number of development days to ‘spend’, it allows them to prioritise their tweaks and changes and get those things fixed which are most important to them without being too much of a drain on developmental resources…

And then that’s it.

Make the changes, test them again, and then put the system live.

But don’t treat “go-live” as a single, one-off event.

Instead treat go-live as a procedure that takes at least a week starting from when the application is transferred to the live or production environment. Ensure that some development resource is allocated to the first week (or few) of the live system, because you can’t guarantee that you’ll have caught every potential problem; and pay particular attention to interfaces with other systems because if one of these goes awry, you could very quickly be causing problems for a number of systems!

Summary

That’s it, basically: the management of the development life cycle is about managing the expectations of the users when you agree the system requirements; about managing the developmental standards and the techniques the developers use; about managing the testing procedures and ultimately about managing the go-live procedure to ensure that the system works without any problems, that it meets their requirements, and that the users are happy with it.

There you go: get yourself away and produce perfect systems from now on…

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards; usability, code-cutting (this article), and testing and go-live.

Code should be clear and understandable

In my current development environment, we don’t use naming conventions for variables, object names and the like, because we considered the standards-based questions:

• What do we need to do to fix this system?
• How long will it take to fix this system?
• How much will it cost to fix this site?
• How likely is it someone will have a problem with this system?
• What are the potential consequences if someone has a problem with this system

…with “naming conventions” in mind, and decided that while some sort of naming conventions were desirable, they weren’t sufficiently important in our environment to prevent something from going live or to ask it to be re-written.

What we do look for is that per project, each developer codes meaningfully and consistently.

In other words, it doesn’t matter whether you want to use t, t_, txt or txt_ as a prefix for text boxes; what is important is that whichever one you decide to use, you use it consistently across your application, and even more importantly that you give your objects and variables meaningful names.

txtFirstname is meaningful; you don’t need to compare this with the on-screen label to guess that it refers to someone’s firstname. Even if txt4 does refer to the fourth field on the screen, it’s not particularly meaningful: it would be of much greater benefit to know what that item represents.

Similarly, if you have a particularly long or complex piece of code, break it up with some brief comments to explain what you’re doing.

For example, I recently reviewed a piece of code I wrote a while ago that carries out a search function contains 75 lines of visual basic, 11 lines of which are comments. I have used the comments to identify each little block of code and explain either what it is doing, or what circumstances have lead us to this particular block of code:

• 'page is valid - Find matching events
• 'Step 1 - create basic SQL command
• 'Step 2 - determine criteria
• 'need to include name
• 'need to include date range
• 'need to include location
• 'need to include event type
• 'Step 3 - stitch together command and criteria
• 'Step 4 - find records
• 'these are the records that have been found
• 'no records have been found

Not only does this mean that if someone else has to amend my code later on it will be easier for them to see which bits are doing what, it is also considerably easier for me to come back to the code at a later date and work out what it’s doing!

On top of that, bear in mind that the variables and objects being used have meaningful names and it’s easy to track what is going on. It also makes debugging and problem-solving much easier too.

Coding in this manner makes your own life easier, and that’s something every developer ought to be in favour of!

Don’t Do The Same Thing More Than Twice

Some people use a stricter version of this rule: that they shouldn’t type the same piece of code twice, but by then ought to have written a re-usable function that they can call as circumstances dictate.

I’m not quite as obsessed about it as this, but I’m firmly behind making my own life easier, so if I find I’m typing out the same sorts of thing repeatedly, I’m going to try and find an easier way to do it.

As a rule of thumb if I find I’m going to have to write out pretty much the same lines of code for a third time, I will look to write a subroutine or function that can be called to repeat the procedure instead.

I usually make third time the charm because frequently this sort of thing will require parameterisation, so it’s just as onerous to write it out as a single parameterised function as it is to write out each line twice, but really the code would be neater and more elegant if this was done every time you need to use a specific function (or set of functions) more than once.

Parameterise Things

Following on from the last point, you can save yourself an awful lot of time if you parameterise things. Imagine you’re asked to produce a report from your database of all of the items currently in stock that cost less than £2.99.

You’ve got two choices: either you can spend a bit more time up-front creating a screen where the users input their search criteria and then you return all of the item details which meet those criteria (in/out of stock, minimum price, maximum price, warehouse etc), or you quickly knock up a single report for the ones less than £2.99, and then a week later you need to do another report for the ones less than £4.99, and then after that you get asked what items are currently in stock which we’ve not used any of in the last three months…

If you parameterise your queries at the outset (making sure not to allow SQL injection attacks into your database), you’ll save yourself work in the long run, because your users can answer their own queries by adjusting their criteria, rather than requiring you or one of your development team to write them a new report each time…

Use Whitespace

Feel free to use whitespace to ensure that the source code of your pages or forms is laid out neatly. Yes, in environments where your source code is not compiled prior to being served to the users (for example any HTML pages), this will result in your pages being a few bytes larger than they actually need to be, but the flip side of this is that your code will be much easier to track and maintain; and that is a price well worth paying in most circumstances.

Templates

Most development platforms and environments will offer some sort of opportunity to use a template. The use of templates is A Good Thing as this will help ensure that while different developers have a different development style, different preferences and so on, it will help keep them in the same ballpark.

How easy it is to use templates depends on your development environment: in Microsoft Access developments, my experience is that a development team will have a ‘standard’ database with various built-in functions and styles, which they will then take a copy of and customise according to preference.

Similarly, when developing in a .NET environment, I have created my own templates (although here they are called ‘Master Pages’) which can be incorporated into new web developments (with different forms of the template suitable for intranet or internet sites).

Possibly the most flexible templates however are those found in Adobe (formerly Macromedia) Dreamweaver, which offers quite a neat template function for web designs: you build your template and attach pages to it. When you make an amendment to your template later it can automatically search through the pages in your site which are attached to that template and apply the changes you have made.

Nice.

Of course, any web-based designs which have been done using properly structured HTML and CSS gain a number of the benefits of using templates anyway, because of course any changes to your CSS rules — assuming that you’ve used a linked stylesheet instead of inline styles — can be immediately applied across multiple HTML pages.

But of course you knew all that anyway, didn’t you?

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards; usability (this article), code-cutting, and testing and go-live.

Developer Styles

Bear in mind that each developer will use slightly different development methods and have a slightly different coding style, and that’s before you even consider the fact that different applications written for different platforms require radically different skillsets and can provide a radically different user experience.

So how can we bring all of these together in such a way as to draw any useful comparison?

Simple: I’ll generalise a lot, and make up examples to suit.

Usability standards ought to be mandatory: if whatever application you are designing doesn’t work in a logical and intuitive manner, it isn’t well enough designed. It really is as simple as that. Highly usable systems will result in less errors being made by the end users, they will result in less problems being reported with the system, and they will result in high levels of user satisfaction.

It’s always worth investing a little time in getting a couple of people to give your site or application a going-over: encourage them to try to generate errors by inputting junk data: after all, your users will be doing this at some point so testing it up front allows you to be sure you’ve covered all of the bases.

Things that look the same should behave in the same way

If you’ve got a series of buttons, or hyperlinks, or whatever else that look the same, they should behave in the same sort of way. If one hyperlink is going to take you to a new page, you wouldn’t expect that clicking on a different hyperlink would just refresh the values in a drop-down list, for example.

Things that behave in the same way should look the same

Exactly the same principle as the one above, just phrased the other way around!

Style things consistently

This one can be difficult, particularly if it’s your first application, or it consists of more than half a dozen pages or forms, because there is a natural tendency to want to differentiate between different sorts of forms.

This is normally along the following lines:

“Hey! Why don’t I make the forms or pages about people in green, and make the maintenance forms blue?”

And it deserves the response No; No; No; No; NO!

The reasons for this are two-fold: firstly, if your application is styled and designed consistently, the users only have to get used to a few different types of form, as they will be likely to assume that forms which look the same as one another will behave in the same sort of manner.

Secondly, we live in a time of multi-tasking now. If someone has half-a-dozen windows open on their computer, it’s going to be easier for them to locate your application if they can just think “that one looks like the application” rather than “that one looks like the administration part of the application; or possibly like the people part of that other application..”

Scrolling

As a rule of thumb, I’ve noticed amongst my users that users have an expectation that they may have to scroll down on web pages, but expect paging or tab-based controls on windows-type applications and are more reluctant to scroll down, although users appear reluctant to scroll horizontally.

That’s just anecdotal and I don’t have any statistics to back it up with, so don’t just take my word for it: watch your own users to see if they behave similarly.

If they do, then follow my scrolling rules of thumb:

• avoid horizontal scrolling on any system
• avoid vertical scrolling on windows applications where you can use tabs or paging controls instead
• feel free to use vertical scrolling on web pages

Focus on user tasks

Don’t add bells and whistles to a form or page just for the sake of it, if they will distract from the job at hand, but equally don’t be afraid of adding additional features to a page if they will benefit your users.

Remember to ask yourself on each page or form: why would the user have visited this form? What would they have wanted to achieve? How can I make that easier for them?

Plain English

Or perhaps I should request that you use simplified anglo-saxon verbiage?

Don’t use jargon, technical terms, management speak or legalese. Aside from making you sound like you’ve been developing with a thesaurus firmly implanted up your backside, they just make things more difficult for your users to understand.

If you can’t explain whatever-it-is in terms that a twelve year old would understand, give up on writing the text yourself. Either get an expert in to do it, or get that twelve year old to do it instead.

Validate User Input

It may sound bleeding obvious — and indeed it is — but you’ll get a lot less junk data submitted to your application if you check that the submitted data is valid. If you are using a web-based application, remember to ensure that validation is always carried out server-side (although you can in addition offer client-side validation) as you cannot rely on client side validation.

Summary

These are just some of the tips that have occurred to me through my time either developing or overseeing developments: if you want to look into usability in more detail, I’d recommend taking a look at Steve Krug’s book Don’t Make Me Think, which is an excellent usability primer, or if you want a quick checklist to refer to, remember Jakob Nielsen’s Ten Usability Heuristics.

I have broken down my thoughts on system design into five distinct pieces: user requirements; development standards (this article); usability, code-cutting, and testing and go-live.

What sort of standards?

That’s really up to the application development team (and/or their line management) to decide what sort of standards are appropriate to a particular development. This will obviously vary somewhat according to the platform the application is being developed for, and the expected users of the system, but some standards that could be considered are:

• Internal coding standards — is your code readable? Are variable names meaningful? Have you used corporate naming conventions?
• External coding standards — does your HTML validate?
• Usability standards — is your system easy and intuitive to use, or do people have to be given specific instructions to prevent them from making mistakes?
• Accessibility standards — can your system be used by people with disabilities?
• Universality standards — can your system be used by people with a different platform and/or browser?

I’m not going to get into the argument here (again) but I tend to see universality and accessibility as part of the same coin: either are preventing someone from using the site, it’s just a question of why; however I’ve specifically listed them separately here because in this case I want to consider them separately.

Standards Enforcement

In any development team, different developers will by nature have different coding practices, different skill sets, and indeed different attitudes towards work. Yet from here we want to arrive at a position where we can be sure any developed systems not only meet our requirements, but also that in the event of the prolonged absence of one developer, someone else would be able to step into their shoes and continue their work.

In a nutshell, those two things — ensuring you hit any external requirements and that your developers can work interchangeably — are, in a nutshell, what standards are all about.

At the managerial level however, it is important to decide which standards are going to be enforced. Any standards which are not enforced will be seen, at best, as ‘guidelines’ and ignored or adapted by developers to suit themselves on a case by case basis.

For example, any system providing a service to the general public in the UK is bound by the Disability Discrimination Act, meaning that you can’t unreasonably place barriers in front of disabled users, that you can’t refuse to employ disabled employees (which means that even your internal systems may need to be accessible) and so on.

In some cases, it goes further than this. Local Government sites in the UK are expected to comply with the WCAG 1.0 Guidelines to at least the ‘AA’ level. My opinion is that these guidelines are outdated, in some cases make little impact on how usable the site is to someone with disabilities, and prevents you from relying on any scripting technologies even if you’ve tested these with accessible technologies.

That said, if it’s mandatory, you’re still going to be expected to do it, at least until the requirements have been revised. But if you want to actually achieve this, you’ve got to enforce it: test for compliance with this and don’t but sites live if they don’t match up.

The only standards you actually have will be the ones you enforce.

Drawing The Lines: Perfection vs Practicality

Which standards you decide must be enforced will depend on your own external pressures: what are you going to be evaluated against?

In an ideal set of circumstances you don’t need to compromise: when you’re developing applications in-house, you’re in control of them and with a minimum of additional effort can ensure that you comply with all internal standards, that your site is accessible to users with disabilities, and that it is secure and robust.

Unfortunately, the circumstances aren’t always ideal. It’s common to find a situation where some, or all of the live code has already been written, or is outside your control. How do you handle that?

Well not surprisingly, there isn’t a one-size fits all answer. It depends.

Really, it’s up to you, your management, or their management as appropriate, but what you need to consider is:

• What do we need to do to fix this system?
• How long will it take to fix this system?
• How much will it cost to fix this site?
• How likely is it someone will have a problem with this system?
• What are the potential consequences if someone has a problem with this system?

These five questions are key questions to ask yourself about your standards.

Imagine asking these questions with regard to a series of variables not being named according to your naming conventions. Is it that important? Will it have an impact on future developments?

If so, then by all means review it. If not, you might want to reconsider whether you need those standards at all…

Now imagine you’re asking those questions because your site is unusable to someone with Firefox. You’re risking potential embarrassment if someone raises the issue and you don’t get it fixed. You’re also risking losing potential customers or clients.

Now imagine it’s because your site doesn’t work with a screen-reader and blind or partially-sighted people can’t use your site. Now it’s not just embarrassment you’re risking, but a potential lawsuit under the DDA. Under these circumstances, you’d probably have to fix it.

But the question that would tend to be asked is not whether it should be fixed; it’s whether it should be fixed now, or whether you should only put the time and investment into doing that when a user reports to you that they are having a problem with it.

It’s your call. I, personally, would probably want to fix it immediately if that was at all feasible, because of the high risk of public embarrassment as well as potential legal action, but you might see the call differently.

You also need to consider whether internal developments and third party systems need to meet the same standards. This usually depends on the reason for those standards: naming conventions, commented code and internal documentation help when maintaining systems. If the third party is responsible for maintaining their systems, maybe they don’t need to follow your coding conventions…

…but presumably you have the same responsibilities regarding accessibility of services you provide, whether or not these were developed by a third-party or by yourself, so it is just as important to ensure that third party code is accessible as yours is (and again you’ll probably have to decide on a case-by-case basis how to handle it if it isn’t).

I have broken down my thoughts on system design into five distinct pieces: user requirements (this article); development standards; usability, code-cutting, and testing and go-live.

What is the system for?

This is the first and most crucial question that needs to be asked at the starting point of any development. What is the system for. Note that this is subtly different from “what is the system expected to do”.

Here the emphasis should not be on what should the system do, as generally if you are replacing an existing system, the users will assume that the new system should work in the same manner, with some nicer colours and bug-fixes thrown in.

However, asking what the system is actually for — in other words which tasks do the users want to accomplish — will enable whoever is assessing the requirements to compare their knowledge of what can technically be accomplished with the tasks that the users need to carry out and possibly suggest new and improved business practices.

For example, let’s take an imaginary set of user requirements:

The users want a system that will handle various types of financial transaction, and want the system to produce a report that will identify transactions on a weekly basis that have satisfied certain criteria.

You could simply produce this report.

Alternatively, if you’d asked what this report was for, you may have found out extra information, for instance the report may be passed to someone who is externally auditing the financial systems, or for someone who is checking against fraud.

Once you’ve got this additional information, there may be other options available that would be more beneficial to the user — if you create the auditor a read-only account that allows them to run these sorts of reports and check the transactions for themselves, then not only do the auditors get more control over the information that they are looking at, but it doesn’t need to be a task that the standard users have to carry out any more.

This fictional example is just to illustrate the importance of knowing why. It is therefore critical that whoever is sent to discuss the system with the user is capable not only of understanding the technical possibilities but of determining and understanding not only the users’ business practices but also business reasons behind them.

Who is the system for, and how secure should it be?

If the system is used by everyone in Department X to monitor the amount of fuel being used by the company’s vehicles, then this only really needs to be placed in some sort of location where only Department X can access it, such as a place on your corporate network.

If on the other hand it was being used to keep track of disciplinary action taken against various employees and/or information relating to ongoing disciplinary cases, and it was required to be published on the internet so that suspended employees and their union representatives could access their own data then it would need to be considerably more secure; you would not want anyone to be able to access this data unless they were a specifically authorised user (this would not only be required for data security, but in a system of this nature it would additionally be required by the Data Protection Act).

You therefore need to choose an appropriate platform and security structure for the system depending upon the importance of the data, the sensitivity of the data, and the potential for harm if the system is compromised. It is theoretically possible to apply the maximum security level to every system, but this would generally not be desirable because you are adding unnecessary development costs in each case.

It is important to decide between the system owners and the system developers what form of security is appropriate and develop to this standard.

For a system of critical importance, where data is particularly sensitive, or where it is most exposed (e.g. applications published on the internet), you may also wish to look at incorporating penetration testing into your plan.

Noting who your users are is of importance too. If your users include the general public, or people who don’t use many other IT systems, then you’ll have to pay particular importance to ease-of-use because the likelihood is that you may be dealing with at least some people who are not particularly computer literate, and if you want your system to be successful, it needs to be (at least relatively) easy to use for everyone.

Write It Down

Once you’ve discussed the requirements with the users, and you’ve come up with a proposal, document it. Write down what you think the system needs to do, write it down, and send it back to the users for confirmation.

It won’t stop arguments (sorry, “discussions”) about the original intentions later on, but it will reduce them — anything you’ve got down in this document, once it has been confirmed, has been agreed.

Depending upon the client/developer relationship this may or may not make a difference to your procedures should the client request changes, but at least you’ve got something to refer back to, and this document can be crucial for the developer who shouldn’t make any decisions that moves the system away from what is agreed in this document without specific authorisation.

From this document, you should be able to produce your Acceptance Critieria before you’ve even carried out any development. The acceptance criteria document is simple: it basically says that if the system does this, this and this, doesn’t need this or that, doesn’t do that, that or that, and that you can run this, that or the other report from it, then the system will be acceptable. If it doesn’t meet these criteria, the system won’t be acceptable.

If you and the users have done your respective jobs properly at this stage, the users will be happy with any system that meets the requirements described in the Acceptance Criteria, and the developers will understand how to produce a system that will meet the users’ needs.

Summary

It sounds simple — and indeed it is — but it brings a great deal of practical benefit to your projects throughout the project lifecycle if you can:

• Understand the business requirements and the business processes
• Understand who will be using your system
• Understand any complications arising from the sort of data being held (business critical, sensitive, personal etc)
• Write it down and get the users to agree acceptance criteria

Yet my development platform of choice is Microsoft’s .NET environment. Many people wrongly assume that using .NET means that you can’t produce standards-compliant accessible code.

They’d be wrong. It’s not necessarily as easy, and you have to make judgement calls from time to time. Here are some of the things I’ve done to try and make my .NET 2.0 applications more standards-compliant and accessible.

But .NET isn’t built for standards-compliance

Well, I don’t know how it’s built, but I do know that it is certainly possible to develop ASP.NET 2.0 sites using web standards. In fact there’s a whole great ruddy resource on precisely that topic on MSDN: Building ASP.NET 2.0 Sites Using Web Standards.

Give it a whirl. You might learn something. Bear in mind though, that the people behind it might not be right every time — for example they suggest that it makes things more accessible if every form field has an accesskey. It doesn’t. Nor does running your site through an automated checker (also suggested here) allow you to state with confidence whether or not your site is accessible.

So I wouldn’t recommend this as a key source of information for accessibility. I would however consider it to be a key source of information for .NET features that relate to accessible design. Just take their accessibility pronouncements with a pinch of salt…

But doesn’t .NET use tables for everything?

A number of .NET controls use tables by default, such as form views, grid views, tree views and the like. You’ve got a number of options here:

1. Don’t use those controls
2. Use those controls and accept that they are going to output tables
3. Use the CSS Friendly Control Adapters

The CSS Friendly control adapters take the code output by .NET and transform it, depending on browser, to more CSS-related output. I have to admit I haven’t looked into these a great deal: partly because I don’t want to server different output depending on how a browser is identified, partly because I don’t trust people’s browser identifications to be accurate, partly because I’ve never got round to it, and partly because my brief glance at the adapters seemed to indicate that they use javascript, and I try to minimise javascript use for reasons of accessibility support.

However, they might be suitable for you, or your environments, and are probably worth a look.

I personally don’t use them, however. I either create controls myself if I need to — for example creating my own paging control using buttons (so as not to be reliant on javascript), or I avoid them — preferring to build my own navigation menus than using TreeView — or I’m perfectly happy that they output tables, such as when I’m using the GridView control to output tabular data.

The ideal way forward would be for .NET to render controls using CSS by default…

[Edit: and it looks as though they might be doing precisely this in .NET 3.0, from what I've read although I've not been able to test this as yet]

…(or at least by some sort of application level switch) so that people wanting to produce standards compliant, css-friendly code can do so without having to jump through additional hoops.

For now though, you’ve got to jump through ‘em.

.NET form labels don’t work

If you’re using Master Pages (a nice template-type feature found in .NET), you’ll find that many of your controls get given prefixes like ctl00_CPH_Body_ which means that if you’ve started out with something like this:

<label for="Name">Name: </label>
<asp:TextBox ID="Name" runat="server"></asp:Textbox>

What will actually be rendered is something unexpected:

<label for="Name">Name: </label>
<input name="ctl00$CPH_Body$txtFirstName" type="text" id="ctl00_CPH_Body_txtFirstName" />

Which isn’t an accessible form control at all: the label is not actually associated with the correct control (indeed, it’s not actually associated with any control now).

But the solution is simple: instead of using a plain HTML label element, use an ASP label instead:

<asp:Label ID="lblName" runat="server" AssociatedControlId="Name"></asp:Label>

Would render as:

<label for="ctl00_CPH_Body_Name" id="ctl00_CPH_Body_lblName" class="label">First Name:</label>

Simple, eh?

And it’s even easier for ASP controls CheckBox, RadioButton, CheckboxList and RadioButton list, because (and thanks to BrettD for spotting this):

The ASP.NET CheckBox, RadioButton, CheckBoxList, and RadioButtonList controls automatically render tags. Be careful, when using these controls, to use the Text attribute to label the text of the controlBuilding ASP.NET 2.0 Sites Using Web Standards (2)

.NET isn’t XHTML-strict compliant

Yes it is. Or rather, it can be. The problem it has is that it doesn’t know that you want to use XHTML strict (defaulting to XHTML 1.0 Transitional). All you have to do is tell it, by including something in the web.config file:

<xhtmlConformance mode ="Strict"/>

Not too difficult, was it?

Errors Are Found In The Output Source Even When There Isn’t An Error

What, you mean like this?

<span id="ctl00_CPH_Body_valSurname" style="color:Red;visibility:hidden;">You must supply a surname for searching</span>

…or more commonly showing an asterisk, with the full error message being shown in a validation summary further down the page.

Yes, some of my earlier .NET 2.0 developments contain this sort of thing. Unless you view the source code (and unless you’re some sort of standards-obsessed anal retentive, you’re not likely to), you wouldn’t notice that in most circumstances.

You might however notice it if your browser doesn’t use CSS (or doesn’t take account of it properly), in which case you’ll find that all of your form controls with associated validation are reporting errors even when there aren’t any errors.

This is quite simple however, and is to do with client side validation. .NET allows the use of client side (javascript) validation, backed up by server side validation if the page cannot be validated with javascript (i.e. javascript doesn’t work, is turned off etc).

In order to do this, it places these error elements in the source code, but tells the browser to use CSS not to display them, and then in the event of an error actually being found, it manipulates the DOM again in order to display the errors.

That’s fine and dandy, assuming you’re using CSS, and you’ve not over-ridden it with your own preferences. However, if this isn’t the case, you report an error every time: including before anyone’s typed anything in, which obviously isn’t ideal.

Fortunately, there’s a simple way around it: simply insist that all validation is carried out server-side rather than client-side. This might mean a slightly increased load on your server, and it might mean it takes ever-so-slightly longer to validate the page, but that’s the compromise you have to make.

And it’s very simple to carry out the change. All you need to do is add EnableClientScript="False" into your .NET validation control, like so:

<asp:RequiredFieldValidator ID="valSurname" runat="server" ControlToValidate="surname" ErrorMessage="You must supply a surname for searching" EnableClientScript="False" cssClass="error">*</asp:RequiredFieldValidator>

And hey presto, nothing in the output HTML source unless there actually is an error.

.NET And The JavaScript Bugbear

A lot of .NET controls use javascript. This isn’t because Microsoft are an evil corporate machine dedicated to the destruction of accessibility and standards-compliance (although you’d never know that, listening to some people), it’s because Microsoft have added additional functions that aren’t supported by HTML and therefore need to use javascript to add these additional features because they simply aren’t there in HTML.

I’ve already described this in more detail, and indeed produced a testcase for javascript postback compatibility to test for precisely this thing.

Basically, as far as .NET and accessibility goes, you cannot comply with WCAG 1.0 if you require javascript postbacks. It’s as simple as that: WCAG 1.0 requires that the site functions without scripting being enabled.

However, if the particular scripting — in this case the javascript postback — is compatible with accessible technologies then it will be possible to comply with WCAG 2.0.

If you’re required to comply with WCAG 1.0, you can’t use javascript postbacks. End of story. Everything on your site will need to be driven by buttons or hyperlinks, and it’s certainly possible to do things that way, you just have to go to a little more trouble (for example, when I created my own button-based paging controls).

If you’re not required to comply with WCAG 1.0, you therefore have a decision to make. If you use only javascript which has been tested to work with accessible technologies (and that’s the reason why I produced the testcase ), then you can use that piece of javascript and you won’t be preventing users with disabilities from accessing your site.

That’s why I tested the javascript postback, and I’m confident that this can be used without discriminating against disabled users; it appears to be widely supported by assistive technology. I wouldn’t however just take my word for it: if you feel you need to, test it yourself, or set up your own test case!

However, your site (or at least those parts of it which required javascript) would be unusable for anyone who couldn’t support javascript, or have it switched off.

That’s your call.

Personally, I’d minimise the use of javascript, and only rely on it if necessary, because I’d rather have a site that will run even with scripting switched off. But if I have to use it, I will.

That’s my call: but then again no-one is insisting ThePickards comply with WCAG 1.0…!