If you need New Zealand public sector websites to be accessible to use them satisfactorily then the “2014 Web Standards Self-Assessments Report” published in November 2015 won’t give you much comfort.
The good news, such that it is, is that the report’s authors appear to be circling in on the root causes of the problem.
“…NZ Government websites are designed and developed in a manner that tends to overlook the range of ways that people access and interact with web content.”
One has to wonder what goes through the minds of website owners, designers, developers and content creators if they “overlook the range of ways that people access and interact with web content”. Isn’t that the very meat and potatoes of the whole web development process? Accessing and interacting with content is the point of a website – and from a range of people. Quickly exposing desired content to an audience and protecting them from overload or unnecessary navigation is the nub of web design. It’s not primarily about creating a pleasing graphic and balanced palette (although that doesn’t hurt). And, it’s most definitely not about slavishly adhering to egregious visual excesses in the name of “branding”.
There is another puzzle here. Commercial (private sector) websites in general have some sort of sales intent. Their purpose is to in some way persuade the user of the value of their business or more specifically to try and sell the user some products or services. The public sector doesn’t have that sales drive: its purpose is to provide service and enable access and interaction using the convenience of the internet. In short, for public sector websites, it’s all about engaging with web content as part of providing a service to the public at large.
So what or where does the deficiency lie? The deficiency is in overlooking “the range of ways”.
In web design, the responsibility to cater for the range of ways that people access or interact with web content is within the scope of the user experience (UX) designer. A usual technique is to create personas. Personas are fictitious composites that are created to represent broad classes of the types of people who are expected to access the website. For example, the Ministry of Justice might expect lawyers, jury members, media representatives, litigants and judges to access its website. A persona could be created for each of these and through the design process the needs of each persona is factored in. The design can be subsequently validated by matching how well it is expected to deliver against the stated needs of each of the personas.
So far so good, but this is the point where I believe that the process fails. Why? Because in the development of the personas it is unlikely that consideration is made of potential impairments. Hence, the potential access (accessibility) needs aren’t embedded into the design process. In the development of some sites, some sort of accessibility review may take place but it is generally too late to make changes. The design signoff processes in the public sector can be so involved that the idea of repeating that process just looks too difficult, let alone having to make the explanations of why it wasn’t right the first time. (As an aside, in the time I’ve been consulting for AccEase I’ve never been asked to review the personas. I’ve checked wireframes, checking off against a range of ways the site will be accessed but pretty much always in the certainty that the range of ways of accessing a site hasn’t been designed in and certainly not included in the personas.)
The notion of developing personas including people with disabilities isn’t new. Shawn Lawton Henry, a renowned web accessibility expert, has even provided example personas.
The “2014 Web Standards Self-Assessments Report” identified three types of people (personas?) that are not properly considered:
- people who don’t use a mouse and instead rely on a keyboard or other input device and software to interact with web content
- people with impaired vision
- people who use special software to help them interpret and understand the structure and relationships between different bits of content on a web page (e.g. what’s a heading, what’s a list item, etc.)
It is up to User Experience designers to ensure that the full range of users are properly catered for.
Where else in the web development lifecycle would it make sense for accessibility to be addressed? Any time later is at severe risk of missing out a design consideration for a range of users. The classic approach is to “test it in” by doing an accessibility assessment once the build is complete and then apply the recommended changes. As noted above, this approach fails as designers are often unwilling to make changes and signoff procedures too cumbersome to achieve meaningful change. This approach also consigns “accessibility” to being an inconvenient afterthought, an encumbrance.
Process vs Technical change
Generally, the resolution to achieving a better state of web accessibility is considered to be the application of the technical elements that afford accessibility. However, I contend that it is a process change that will lead to a better state of web accessibility in our public sector websites. The technical elements do, of course, need to be applied but at present that fails to happen as there are often no explicit requirements generated in the user experience design.
In simple terms, let’s first think of the user (the ends) and then of the standards (the means).
