Skip to content

Category: commentary

It’s time to legislate against digital access discrimination in Australia

A few days ago I was alerted by a colleague as to a news item on Pro bono News titled ‘Disability Groups Call For Accessible ICT in Public Service Workplaces’.  In the news item it talks about the woefully low 3.6% employment rate of people with a disability in the Federal public service, and how much of this can be attributed to inaccessible ICT procurement policies. The argument is that if there is inaccessible equipment, including computers and websites, then it is difficult for people with a disability to stay employed in a government role.

However, what the article glosses over is that the Federal government in fact has some very good policy relating to ICT procurement for people with disability. The larger issue is why then does it not work in practice, and what can be done about it?  I thought it’d be a good time to briefly reflect on how web accessibility has been handled in government circles to date, and the desperate need to update our ancient disability discrimination laws to fix it.

WCAG? What WCAG?

The first internationally adopted standard in relation to the creation of accessible web content is generally considered to be the Web Content Accessibility Guidelines (WCAG) 1.0, released by the World Wide Web Consortium (W3C) in 1999.  While many countries including the USA and New Zealand legislated this standard, Australia was essentially missing in action with ad-hoc policy across the Federal government and various state governments. While there were some exceptions to this such as Victoria who took the WCAG 1.0 standard a little more seriously than others, broadly speaking Australia did not actively embrace the provision of accessible content in government.

Maguire V SOCOG

It is then perhaps with some irony that in 2000 the eyes of the world turned to Australia to see what would happen when the strength of WCAG 1.0 was put to a legal test. In the Maguire V Sydney Organising Committee for the Olympic Games (SOCOG) case, a blind man took SOCOG to the then-named Australian Human Rights and Equal Opportunity Commission (HREOC) due to the Sydney 2000 Olympics website being inaccessible making it impossible to purchase tickets and keep up with the Games activities for assistive technology users. Maguire discusses his experience in a video created by the now-more-simpler-named Australian Human Rights Commission (AHRC):

As noted into the video, Maguire ultimately won the case but at a massive personal cost. The reason it is such a difficult process relates to the legal framework designed to protect people with a disability against discrimination, the Disability Discrimination Act of 1992 (DDA).

The legal process

The biggest issue in fighting the lack of technology support as a person with a disability is how the DDA handles technology – or rather the lack of it. Currently there is no reference to anything related to Information and Communications Technology (ICT, computers, the Internet or anything that could specifically address a person with a disability that cannot access online information in the DDA. There is, however, an advisory note published in 2014 by the AHRC which explains that Section 24 can apply. It is explained as follows:

The provision of information and online services through the web is a service covered by the DDA. Equal access for people with a disability in this area is required by the DDA where it can reasonably be provided. This requirement applies to any individual or organisation developing a website or other web resource in Australia or placing or maintaining a web resource on an Australian server. This includes web pages and other resources developed or maintained for purposes related to employment; education; provision of services including professional services, banking, insurance or financial services, entertainment or recreation, telecommunications services, public transport services, or government services; sale or rental of real estate; sport; activities of voluntary associations; or administration of Commonwealth laws and programs. All these are areas specifically covered by the DDA.

In addition to these specific areas, provision of any other information or other goods, services or facilities through the internet is a service, and as such, discrimination in the provision of this service is covered by the DDA. The DDA applies to services whether provided for payment or not.”

Unfortunately, while the note suggests certainty, it also highlights the long bow that must be drawn in recognising access to the Internet as a service. Furthermore, it does not recognise the most critical part of the argument and that is that barriers to online information are not just about denial of service, but denial of an essential service. As the DDA does not specifically mention this and the legislation pre-dates the arrival of the World Wide Web for most people, it is unable to enforce online access. Therefore, the DDA is broken. As such, policy – even good policy – cannot rectify it.

Good policy is no substitute for legislation

The frustration with the lack of ICT support in the DDA is that there has been a lot of good policy created that should be helpful in addressing inequity. The problem is that it has no teeth. While Australia was slow in adopting WCAG 1.0, it did a much better job in adopting WCAG 2.0 which remains the current Australian requirement. Shortly after the arrival of WCAG 2.0 in 2008, the Federal government created the National Transition Strategy (NTS) which set specific deadlines for Federal government websites to make their content accessible. The plan was for all websites to conform to the Level A target of WCAG 2.0 by the end of 2012 and Level AA by the end of 2014. The states and local governments also got on board, and it seemed that web accessibility was soon going to be a thing of the past.

However, an interim report card after the first deadline indicated that only 26% of websites self-reported to be WCAG 2.0 Level A compliant. While the government saw this as largely good news as it had got the accessibity of government websites from near-0% to 26%, the disability community was less than impressed and the final report was never released to the public.

Policies today

So, coming back to the present, what policies are in place to ensure that people with a disability can gain effective access to online content and get jobs that require online access? Well there have been some positives. The two most notable in government circles is the Digital Service Standard (DSS) in which point 9 specifically refers to accessibility. As such, there is certainly good policy to say that the Federal government should be making its content accessible. In relation to procurement, there has also been progress. As of last year, there is a specific disability ICT procurement standard based on an almost direct text adoption of the European Standard (EN 301 549). The Federal government was so excited about the work, it committed to its adoption before the standard was even finished!  When these efforts are combined with the overall AHRC ruling on the relevance of the DDA, it should be the case that Australia is a beacon of digital access. Unfortunately, in practical terms, these policies have little impact.

The DDA doesn’t work – let’s fix it

The upshot is that the policies we have do not work despite a lot of passionate and dedicated people in government trying to fix it. It is clear that unless there is specific legislation to handle ICT discrimination for people with a disability, it will continue to be the case that policies can be ignored without any consequences, putting the pressure on individuals with disabilities to lodge a claim.

As such, I join the disability groups mentioned in the news item at the start of this article in a call for change. However, in my view there’s no point in creating more internal government policy as it clearly doesn’t work. It seems ridiculous that 18 years after the Maguire case, the processes for addressing online access issues largely remain the same.  The time has come to fix the law itself – to update the DDA so that digital access is acknowledged as an essential human right, and by doing so a clear case can be made that failure to abide by the provision of digital access has enforceable consequences.

WCAG 2.1 Candidate Recommendation – what it means for Level AA compliance

In January 2018, the hard work of W3C resulted in its new   Web Content Accessibility Guidelines (WCAG) 2.1 standard reaching Candidate Recommendation stage.  This  means that, barring any significant issues in its real-world testing, the standard is close to completion and on track for its mid-2018 release date.

Last year I wrote an article titled WCAG 2.1 draft: reflections on the new guidelines and success criteria.  It’s fair to say that a lot has changed since then and that is ultimately a good thing. Importantly, the purpose of WCAG 2.1 is NOT to replace the well-established WCAG 2.0 standard, but rather to extend support for the mobile web. In my view, WCAG 2.1 as it stands does this very well with some additional success criteria added to existing guidelines, and a much-needed focus on supporting mobile platforms by providing two new guidelines.

With WCAG 2.1 reaching a near-complete stage its  a great time to look at all this in a bit more detail and focus on what additional work would be required by ICT professionals to meet WCAG 2.1 Level AA compliance.

Before we get started, it’s important to highlight two things: firstly, I’m not going to go through all the guidelines and success criteria associated with WCAG 2.0, just the WCAG 2.1 extensions.  If you’d like more information on the original WCAG 2.0, I’d be happy to provide you with some resources to get up-to-date with the international standard.

Secondly, I’m going to focus particularly on Level AA compliance. A number of the new WCAG 2.1 success criteria are Level AAA so for now I’ll leave those out given most policy and legislative frameworks don’t go to Level AAA.

Two new guidelines

So with those things in mind, let’s start with the two new guidelines. The addition of the guidelines brings the total in WCAG 2.1 to 14 with both guidelines sitting under the Operable design principle. The new guidelines are:

  • 2.5 Pointer Accessible: Make it easier for users to operate pointer functionality.
  • 2.6 Additional sensor inputs: Ensure that device sensor inputs are not a barrier for users.

Guideline 2.5 is focused on making sure that whatever type of pointer is being used, such as a mouse pointer, a finger interacting with a touch screen, an electronic pencil/stylus or a laser pointer, all functions should work correctly. It may be the case that a person with a disability finds it easier to use one type of pointing device over another, so from an accessibility standpoint all options should be available.

Guideline 2.6 relates to the use of sensor inputs such as a gyroscope or accelerometer found on mobile devices. From an accessibility standpoint, it may be the case that users can’t operate these sensors such as the inability to tilt a mobile phone if it is mounted on a wheelchair. As such, it is essential that people with disabilities are able to achieve the same outcome through the user interface if they are unable to use a sensor-based input method.

In addition to the two new guidelines, there are also new success criteria that have been added to existing guidelines. The following is a list of all Level A and AA WCAG 2.1 success criteria extensions.

WCAG 2.1 Level A

Success Criterion 2.4.11: Character Key Shortcuts

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

  • Turn off
  • Remap
  • Active only on focus

Success Criterion .2.4.12: Label in Name

For user interface components with labels that include text or images of text, the name contains the text presented visually.

Success Criterion 2.5.1: Pointer Gestures

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

Success Criterion 2.5.2: Pointer Cancellation

For functionality that can be operated using a single pointer, at least one of the following is true:

  • No Down-Event
  • Abort or Undo
  • Up Reversal
  • Essential

Success Criterion 2.6.1: Motion Actuation

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

  • Supported Interface
  • Essential

These essential WCAG 2.1 success criteria demonstrate the importance of catering for people with disabilities on the mobile platform.  Success criteria 2.4.11 and 2.4.12 add additional support in helping users navigate and find content by ensuring that customised keyboard shortcuts don’t interfere with assistive technology and improvements in labelling identification.  The two success criteria 2.5.1 and 2.5.2 explain the importance of making sure that multi-gesture commands can be achieved using a pointer and that there is a consistent technique to cancel the action. The final success criteria in this list, 2.6.1, explains that the commands reliant on the movement of a device should also be achievable through the standard user interface.

One of the concerns that has been raised through the WCAG 2.1 process is that several of these success criteria have an ‘essential’ element which is viewed by many as a way in which developers can avoid the need to implement accessibility with the justification being that the design is essential to the functionality of the web content. However, I suspect in practical terms it will be difficult for a developer to argue that other accommodations are not possible if it is obvious that alternative interface controls could have addressed the issue, so it will be interesting going forward to see under what circumstances the ‘essential’ argument is put forward as a way of avoiding some WCAG 2. success criteria.

WCAG 2.1 Level AA

Success Criterion 1.3.4: Identify Common Purpose

The meaning of each input field collecting information about the user can be programmatically determined when:

  • The input field has a meaning that maps to the HTML 5.2 Autofill field names; and
  • The content is implemented using technologies with support for identifying the expected meaning for form input data.

Success Criterion 1.4.10: Reflow

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels;

Except for parts of the content which require two-dimensional layout for usage or meaning.

Success Criterion 1.4.11: Non-Text Contrast

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

  • User Interface Components
  • Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
  • Graphical Objects
  • Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Success Criterion 1.4.12: Text Spacing

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;

Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts which do not make use of one or more of these text style properties in written text can conform using only the properties that are used.

Success Criterion 1.4.13: Content on Hover or Focus

Where receiving and removing pointer hover or keyboard focus triggers additional content to become visible and hidden, respectively, the following are true:

  • Dismissable
  • Hoverable
  • Persistent

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

Success Criterion 2.6.2: Orientation

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

While many of the success criteria here may initially appear difficult to implement, the bundling of 1.4.x success criteria together make it helpful in understanding that these are all related to visual improvements. I’m particularly pleased to see that the issue of the infamous ‘double scrollbar’ scenario that screen magnification users face so often, particularly on small displays, is addressed to some degree here along with contrast elements, text scaling and hover issues. It is interesting to note again as to the remarkably specific level of detail in some of these success criteria and it’ll be interesting to see if the real-world testing confirms these values prior to the final WCAG 2.1 release.

I’m also pleased to see Orientation make it this far, and out of all the new success criteria I suspect this will be the thing that resolves the most frustration for people with disabilities overall on a mobile device. When a mobile website or app forces the user to use their device in portrait or landscape for no apparent reason it is a great frustration and significantly affects how the device can be used as it can change the reach of buttons, make swipe gestures more awkward or affect the use of screen real estate. While there is another ‘essential’ statement creeping in here, it’s been my experience that there are few apps that lock in an orientation that really need to do so, which leads me to be optimistic about the implementation  of this one.

Where to from here?

From here, it’s likely that WCAG 2.1 will be released this year as promised, and the take-away message for ICT professionals is to get ready to consider the access implications of mobile-specific elements suchas multiple input methods and sensor integration. For accessibility professionals, the biggest message here is that testing the accessibility of web content on a mobile device is no longer optional and new testing processes will need to be established.

That said, it’s been exciting through my W3C work to see the standard being developed and I’d like to say a big thank you to all the W3C staff, invited experts and volunteers who continue to give up their time to ensure that the mobile web receives a much-needed accessibility focus through the development of WCAG 2.1.

NOTE: at this time of writing, WCAG 2.1 is a Candidate Recommendation and is NOT an official W3C standard. As such, the guidelines and success criteria discussed in this article may differ from the final W3C recommendation. 

Top 5 reasons why online voting is essential for people with disabilities

If you live in Australia, its highly likely that you’re aware of the upcoming marriage equality postal vote – or plebiscite – or household survey – to be held later this year. For the benefit of international readers, Australia is currently in the midst of a same-sex marriage debate, and the best way to progress it has been a hotly debated topic both in an out of parliament for several years. it is now most likely the process will be completed via a postal survey.  

If you read through the news items and social media posts on the topic, it’s certainly fair to say the whole process is somewhat controversial. Issues currently being discussed include whether it’s necessary to spend $AUD122 million on the process given its non-binding, whether the process is needed at all when polls consistently show two-thirds of Australians are in favour of marriage equality, and whether the use of a postal vote will unfairly skew the results in favour of older Australians given most people under the age of 25 have probably never physically put a letter of theirs in a post box.   

While all these issues are important, the one that concerns me the most is that people with disabilities may not have the opportunity to have their say at all due to the unfortunate return to the use of inaccessible print media.

It is highly ironic that the Australian Bureau of Statistics (ABS), the government department given the responsibility for running the postal survey, felt that so many Australians now favour online as a means for completing government information requests that the last Census was held online for the first time. While the census didn’t exactly go according to plan due to crashes and alleged cyberattacks, it did highlight that completing such requests online is the preferred method for both government and the general public. Furthermore, many core government services including Centrelink, Medicare and the Australian Tax Office now put a heavy focus on accessing information online through the MyGov portal, again putting forward the argument that interacting with government services online is the best way to go.

So why then do we continue to see a return to archaic forms of voting such as postal votes that focus on the use of paper? Even during general elections, the emphasis is still on confirming your registration in a printed book and filling out a ballot form on paper. It seems that the reason for this is a combination of legislative restrictions and tradition. While I appreciate that the ‘if it ain’t broke, don’t fix it’ model may hold up for some, my argument here is that the system is broken for people with disabilities, and we have the technology to fix it, so it’s about time that we did.

With that in mind, here are my top five reasons for why it is essential that people with disabilities are given the opportunity to vote online.

1.    Accessibility

The most significant reason why all voting opportunities should go online is due to accessibility. The technical issues in the last Australian Census overshadowed the fantastic reality that for the first time, people with disabilities were able to independently participate in the completion of the Census form using the assistive technology of their choice. The website was largely compliant to the WCAG 2.0 standard meaning it worked well for most people with disabilities. As such, barriers relating to the printed version of the Census were no longer an issue which included the print being too small for people with low vision, completely inaccessible questions to people who were blind, and difficult-to-read questions for people that had cognitive disabilities. The Census demonstrated that it is possible to have an accessible online portal that can gather information on a national scale, so there’s not much of a technical argument that a similar process could not be used for voting.  

2.    Improves accuracy and security

As a legally blind person, it is an uncomfortable reality that the easiest way for me to vote will be to ask someone I trust to help me fill out the form. While I’m fortunate to have a number of people around me that are likely to respect my wishes, there’s no guarantee that this will be the case and I have no way to check if the form is filled out correctly. With the right security checks, an online voting system could ensure that I am who I say I am and that my vote is as I intended. This is already the case with sensitive government information relating to payments, health and tax so there’s no reason why such checks can’t be carried out in a voting context. The process could even be connected to the secure MyGov account as a way of crossing my name off the electoral roll.

3.    Easier to complete

In the last Federal election, I was surprised when I received the Senate ballot paper as it seemed to be as long as an unravelled toilet roll and printed in micro-font. Compare the process of filling this out with an online system whereby you can make the text as large as you need it to be in the colours most comfortable for your eyes, or even have it read out to you with an input method of your choice. Many people with disabilities already have their home computer, smartphone or tablet optimised for their needs so completing the voting process through this method is not only accessible but much easier.

Furthermore, providing the ability to complete a voting process online removes the need to travel to a polling place, a task often challenging for people with disabilities who may not be able to drive or are unfamiliar with a polling location.

4.    Removes the need for specialist solutions

In response to the postal survey backlash from organisations such as Blind Citizens Australia and Media Access Australia, the ABS have now agreed that there will be some form of telephone system for people who are blind to complete the marriage equality survey. While this is great news, there are few details at this time about how the process will work and ultimately it seems like a backwards step whereby one government department announces a postal survey followed by another government department scrambling to figure out how to make it work for people who are blind. Online voting removes the need to create yet another process just for people with disabilities and streamlines the process for everyone.

5.    Cheaper

If the four arguments above haven’t convinced you that online voting is the way to go, I’m hoping that the significantly reduced cost that online voting brings will be a good motivator in changing your opinion. Returning to the Census again, a factor in it going online was so the ABS didn’t have to spend so much money on paper, or staff to distribute and collect it. If the process moves online then it becomes cheaper. It also removes the cost of specialist solutions and has the added bonus of making it much easier to tally the votes at the end as its already stored electronically.

It’s my opinion that the right to vote in any country is a privilege and something that I take seriously as part of a citizen of this country. While issues and elections will come and go, the fundamental right to independently participate in them is absolutely critical. It’s my hope that the next time the government requests my opinion on an issue I’m able to provide it without the help of a third party.  

Top 5 web accessibility complaints and how to address them

It’s a common scenario – you’re a web developer on a tight deadline. You think everything is pretty much wrapped up for the client until that pesky accessibility-related request crops up. It might be an unexpected need to caption a video, or perhaps it’s the need to change that cool rollover effect you spent three days mastering. Worse still, it may be that killer last-minute web accessibity check that reveals the entire project is in jeopardy resulting in long nights and budget problems as it all gets fixed up.

But does it have to be this way? If you ask a room full of accessibility specialists, the answer will be a resounding ‘no’. However, if you ask a room full of web designers and developers, the response is likely to be ‘yes, because there’s no other choice – accessibility is hard, time-consuming and expensive’.

At the risk of having other accessibility specialists grab their pitchforks and march on my place, I’m going to say that both groups are right – to a point. Web developers and other associated ICT professionals are absolutely correct in saying that accessibility can be hard, it can be time-consuming and it can be expensive. However, I’d disagree that there’s no other choice. If the key accessibity issues are incorporated into work practices, meaning that issues are addressed in the early stages of a web project, there’s no need for accessibility to be hard, time-consuming or expensive, and I base this on over a decade of experience in the field.

So, with that in mind, here’s a list of the five most common complaints web developers have raised with me about accessibility and some practical tips on how to address them.

1.    Web accessibility can be expensive – if you only consider it at the end of a project

The biggest complaint people raise with me when I run workshops and training is that web accessibility is expensive. I’d agree that if you don’t consider compliance to the current WCAG standard during the development process then this is absolutely true. However, most aspects of WCAG do not require additional work, but rather provide a different way of working. For example, adding descriptive links instead of ‘read more’ isn’t much of an effort, making sure there’s an online language declaration can be done pretty quickly and not using colour to indicate a change of context doesn’t require any effort at all.  In fairness, there are some things that may incur an extra cost such as audio describing a video so I wouldn’t say definitively that accessibility costs nothing, but if staff are trained to incorporate web accessibility into work practices, the cost will be barely noticed in the budget of a typical web project.

2.    Web accessibility is time-consuming – if you don’t learn WCAG

It’s important to acknowledge right away that while the W3C’s current WCAG standard is a really big deal to me, it only represents a small part of what web developers need to consider. As such, I’m not asking you to dedicate your life and career to the pursuit of web accessibility, but it is important to be aware of what’s in the WCAG standard and how it applies to your work. I’d estimate that about two-thirds of WCAG 2.0 Level AA, the typical implementation target, requires no noticeable extra time in their implementation, it’s more about working smarter than harder. Granted that still leaves the other third but most of those get faster with practice only leaving a few requirements by my count that actually require a bit of additional planning. The upshot is that if you can get your head around WCAG and adjust your work processes accordingly, you’ll achieve most of the standard during the normal development process and will be able to plan effectively for the additional parts such as captioning a video – which is the next point on this list.

3.    Captioning a video is a pain – unless you’re aware of all the fantastic free tools out there to help you.

It’s interesting when giving a presentation just before a big web project, going through the WCAG 2.0 At A Glance document and hearing the groans when ‘captioning a video’ is mentioned as a Level A requirement. It’s been my experience that the rest are generally considered okay – no major complaints about alternative text, no issue with colour contrast, but captioning a video is perceived to be a big job. The important thing to acknowledge is that yes, captioning a video can be a big job, but it doesn’t have to be. There are many great free tools available to help you with this work, the first being YouTube’s automated captions in which Google can caption your video for you and you can use those captions for other projects. Importantly these captions are unlikely to be 100% accurate, and depending on the audio the quality will range significantly, but what the auto-captions are able to do well is get the timing right which is half the battle. After that you can then turn to many of the other free captioning suites online, or do your captioning from scratch if the auto-captions just don’t work. My personal favourite online captioning tool is Amara.org but there’s one built into YouTube itself and WGBH’s recent tool CADET is getting great reviews as well. In the course I teach, we have a captioning assignment and most students go into it thinking it’ll be really hard work and are generally surprised at how quickly and easily captioning a video can be done with the right tools.

4.    Accessible websites can be boring and ugly – if you’re not creative enough

If I didn’t have people storming my house after my opening remarks, they probably are now. However, it is important to address this reoccurring point that ‘accessibility = boring’ or ‘accessibility = ugly’. The first point I’d make here is that WCAG was not designed to stop your creativity. In fact, the millions of people with disabilities out there that use the web want to experience your creativity, your flair and your hard work, so please don’t hold back! Secondly, there’s lots of great websites out there that demonstrate you can be creative and accessible. The BBC website is one of the most media-rich websites in the world and has everything from videos to children’s games, and has consistently done a great job in making things accessible. As mentioned previously, most of WCAG is about the way you can do things, not an extra thing to stop you doing things, so keep the creative ideas flowing so we can all enjoy them.

5.    Accessibility can affect security – until you use the techniques that give you the best of both worlds

Out of all the complaints listed, this is the one that in my opinion is the most legitimate concern. You don’t have to look too far in the news to witness cyberattacks sweeping the world, and there’s no way security should be sacrificed to make a website accessible – and I’m absolutely not asking you to do so. Security issues generally need to be dealt with on a case-by-case basis, but what I would say is that in most cases there are accessible ways of implementing popular security mechanisms on a website.

For example, I’m often asked about CATPCHAs. I’ve recently completed some research as part of the W3C Research Questions Task Force (RQTF) and it’s pretty clear from the literature out there that traditional CAPTCHAs are no longer as effective as they used to be. As such, it’s important to consider alternatives not just for people with disabilities or people unfamiliar with the English character set but to also get something with improved security. E-mail verification, for example, is a popular alternative that is generally considered more secure and accessible.

A second example is giving people more time to complete online processes such as accessing government records. Understandably for security reasons you don’t want to leave this open to anyone for very long, but WCAG says people should have enough time. One solution is to provide a ‘+5 minutes’ button on the website. This confirms that the user is still present which addresses the security concerns, and also provides that bit of extra time needed for a person with a disability using a screen reader to complete the task. These are just two examples and in most security-related scenarios presented to me I’ve been able to find a solution that works for everyone. Furthermore, with more developments in biometrics and alternative authentication techniques it’s likely this will become even easier to address in the future.

So that’s a short overview of the five most common complaints made to me regarding accessibility and some practical tips on how to address them. If you’d like to keep up with other accessibility news you’re welcome to subscribe to my newsletter by e-mailing newsletter@hollier.info  with ‘subscribe’ in the subject line or you can follow me on Twitter @scotthollier.   

City of Fremantle commits to escaping the accessibility island

I recently ran a workshop titled ‘Escaping the Accessibility Island’ for approximately 40 people at the office of the City of Fremantle. The workshop was designed to support the City of Fremantle as it continues to update its web presence and the accessibility of public-facing ICT infrastructure by incorporating digital accessibility techniques across different organisational roles.

The workshop included a hands-on practical exercise of using a screen reader, an overview of the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0 and how it applied across a variety of roles including policy officers, ICT professionals, content producers, marketing staff and communication specialists. The workshop also provided some insights into how to perform visual checks on web content and use an automated tool.

While the workshop provided valuable information in how staff can incorporate accessibility into their work practices, there was also a lot of fun had by all as the practical aspects of digital accessibility were explored.  I’d like to take this opportunity to sincerely thank everyone at the City of Fremantle for the opportunity to provide you with accessibility training.

If you would like to have a digital access training workshop run for your organisation, you’re more than welcome to get in touch.  All the details can be found on the hollier.info Contacts page.