Skip to content

Category: commentary

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.

Screen readers and web browsers – what’s the best pairing for testing?

Testing web content for accessibility can be a difficult task, but fortunately there’s some great guidance from W3C in the form of the Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0. However, many people get stuck at Step 1 – defining the evaluation scope.  While setting a conformance target is generally straightforward such as WCAG 2.0 Level AA, it’s much harder to decide baseline-related issues such as which assistive technologies should be used for testing against the WCAG 2.0 Success Criteria and in which browsers the content should be displayed.  Recently encouraged by a student question in the course I teach, I’ve put together some information on the topic for you to consider.  

Before outlining my thoughts though there’s two important things to keep in mind: firstly, if you are doing a web audit for a client, the answer to ‘what browser and screen readers should I use to form a baseline?’ should generally be answered as ‘whatever the client wants’.  You’re certainly welcome to point them to this post if it helps to explain your point of view about accuracy of testing, but I appreciate there may be very specific reasons why the client wants to test out, say, JAWS with Chrome.  While some pairings in industry may be unusual, there’s often a method to the madness especially in locked-down enterprise-level systems where the Standard Operating Environment (SOE) gets changed for no one. Secondly, keep in mind that this assessment is a point in time and is purely my opinion based on working in the industry and many anecdotal conversations with screen reader users, so this can change quickly.

With that in mind, here are my recommended pairings for screen readers and web browsers.

1.    NVDA and Mozilla Firefox

If you want to test in a traditional desktop environment on a Windows platform, it’s hard to go past NVDA with Firefox.  NVDA is a fantastic screen reader with the developers at NV Access working hard to ensure the screen reader is up-to-date with great support across a number of recent Windows versions.  In addition, updates tend to come out very quickly ensuring that it caters for changes to web standards and best of all, it’s free. 

 The benefits of NVDA are also in many ways the benefits of Firefox. The browser focuses heavily on standards-compliance with a legacy of effective support in this area and it plays very well with NVDA. As Firefox is also updated regularly you’re well placed to use these two together to maximise your accessibility testing with a degree of certainty for the results and at no charge to your organisation.

 2.    JAWS and Microsoft Internet Explorer

While NVDA and Firefox is arguably the most accurate paring for testing, there’s no denying that JAWS remains the king of screen readers and it’s likely that organisations will want to know how things go for JAWS users as a result.  In my opinion JAWS testing should remain with Microsoft Internet Explorer despite the browser being so old that its existence in Windows 10 is barely acknowledged to the point that you probably didn’t realise it’s still there.  The reality is that there’s still a lot of screen reader users that rely on old versions of JAWS due to the cost of upgrading, and its slow upgrade cycle has caused issues for it with other more modern web browsers.  People testing websites often get frustrated with this combination as Internet Explorer is not the most standards-compliant browser, and JAWS certainly has its own quirks so the two combined may show up errors that you don’t believe most users would experience, yet this pairing is still reflective of a large number of desktop users and you may need to consider this if your organisation has JAWS users.

 3.    VoiceOver (iOS) and Safari (iOS)

 With WCAG 2.1 on the way a time is coming when testing on a mobile will be an essential part of WCAG conformance, and with that in mind it’s important to know which pairing is best for mobile devices. On iOS devices such as an iPhone or iPad, it’s a pretty easy choice – use the built-in VoiceOver screen reader with the built-in Safari browser. Both work great together and in my experience there’s no other iOS browser that comes close to VoiceOver support.

 4.    Android TalkBack and Google Chrome

As noted above, with WCAG 2.1 coming it’s likely you will need to test on mobile devices, and the best Android option is to test using the TalkBack screen reader with the Chrome browser which works very well, better than any other web browser I’ve tested.  If you have to choose only one mobile platform for testing though I’d go iOS at this point as while Android dominates the market in the general population, Apple iOS is far more popular among people who are blind or vision impaired – and I’m acknowledging this despite being primarily an Android user myself.  That said, there’s nothing wrong in using Android for testing and if you do, go for TalkBack with Chrome.

5.    ChromeVox and Google Chrome (desktop)

From a  testing perspective, you may not be aware that there’ is a little-known screen reader tucked away for users of Google Chrome called ChromeVox, and this screen reader is also found in Chromebooks. While its not commonly used by people with vision disabilities, it can be a useful pairing for testing purposes  Just be mindful that while it can help pick up issues, the overall experience is not going to be reflective of most screen reader users hence its further down this list. That said, Chrome is an excellent browser and both Chrome and ChromeVox are free. Furthermore, given the popularity of Chrome as a desktop web browser there’s a good chance it’s already on your computer.

6.    Windows 10 Narrator and Edge – in the near future

 At this point, screen reader purists are likely to start questioning my sanity by including Windows Narrator on the list paired with anything. I certainly won’t argue that Narrator in Windows 2000, XP, Vista and 7 was a terrible screen reader.  However, updates in Windows 8 and significant improvements in Windows 10 including the Braille support coming soon highlight its significant improvements.  I’ve used Narrator for testing and while it should certainly be no higher than six on this list, it has the advantage of being built-in so people are likely to have it, and Edge is a reasonably standards-compliant browser – well, significantly more so than Internet Explorer anyway!  At the moment Microsoft still recommends Narrator users in Windows 10 use Internet Explorer, but with updates to both Narrator and Edge in the insider preview of Windows 10 likely to be released later in the year.  This will become an option for testing.  Not the best option, but good enough to be an option if your machine at work is locked down like a fortress and you have no other choice.  

7.    VoiceOver (Mac) and Safari (Mac)

I’ll be the first to admit that VoiceOver and Safari on iOS are fantastic, but VoiceOver on Mac OS and Safari on the desktop is in a desperate need for a massive overhaul.  It’s unfortunate that VoiceOver on a Mac is good enough that you don’t really need another screen reader, but not good enough when its functionality is compared to other screen readers on other platforms. If you specifically have a blind user in your organisation that only uses VoiceOver on a Mac, then your best option is to test the content in Safari. I should stress that my opinion here is not because I particularly dislike VoiceOver – indeed it was the introduction of VoiceOver in Mac OS 10.4 Tiger that is credited for having the first fully-fledged screen reader in a desktop OS and that deserves respect, but its way overdue for an update.

So that’s a bit of an overview of my favoured pairings of screen readers with web browsers from a testing perspective.  Hope it helps.