Category: Web accessibility

The Web Content Accessibility Guidelines (WCAG) are meant to serve as instructional for developers and designers alike as they deploy web-based content. While WCAG’s “web-based content” guidelines refer to any website or application developed for use at home, work, or the public, they have not been explicitly designated as best practice guidelines for kiosk and public devices for self-service usage.

When the topic of kiosk accessibility arises, WCAG and Section 508 guidelines are not the first regulation that come to mind. Instead, the American Disabilities Act (ADA) offers specific hardware requirements for kiosk manufacturers and deployers. Details like screen height, keyboard reach, and approach clearances for wheelchair access are critical factors in the accessibility of a device for differently abled individuals.

What About Kiosk Hardware?

Physical kiosk hardware can be easily measured, tested, and monitored for ADA compliance while kiosk software and the applications that run on kiosks are a slightly different beast. The kiosk application or website should use WCAG as instructional for best practices, but the program will need additional accessibility programs and/or hardware support in order to fully function for the differently abled.

Take, for instance, a kiosk built in line with all ADA compliance rules. The web application running the transaction or conveying information should certainly offer the recommended non-text content, video & audio alternatives, and keyboard accessible content recommended to be viewable by those with vision or hearing impairments. Unfortunately, even if the application follows all of the WCAG guidelines, the kiosk may not be compliant if it does not offer physical options, supplemental hardware, and/or add on applications that make these features accessible.

Applying WCAG to Kiosk Applications

For instance, even if the website or application integrates appropriate audio alternatives for written content, it will still require software such as JAWS and a set of headphones for users to hear that content. Similarly, if the website or application incorporates captioning for those that are hearing impaired, the proper accessible keyboard options and/or zoom text app must also be available for users to navigate easily.

In short, developing the website to be compliant only gets physical kiosk deployments half way there. The kiosk needs to utilize the proper accessible tools and hardware to leverage the accessibility features implemented.

Additionally, the prospective user’s physical constraints can heavily impact the design needs of the application. One example; navigational items need to be low enough for those with physical limitations due to wheelchair height and/or an individual’s ability to raise their arms. The location of the navigation can be lowered by adding an accessibility button to the bottom of the screen that shifts the location of all buttons to the bottom of the touchscreen. A second option would be to build the application locating key navigation buttons at the bottom of the page. In both cases, these are application or website design features that could be helpful to consider and would alleviate the need to build adjustable hardware or high/low kiosks.

Design with Accessibility in Mind

As often advocated by accessibility experts, designing with accessibility in mind is an important part to a successful website or application. Kiosk projects are often begun after the application development is complete. Many browser based applications and websites currently deployed, find themselves “kiosked” into a locked down, public facing application. As a result, if the initial website or application is not compliant, it may be a costly expense both in time and in resources for a redesign or post-design accessibility update. In this way, kiosk applications are no different from browser-based applications or websites. They require advanced planning in order to make the appropriate decisions from the beginning that will benefit and improve accessibility without making it a late-game decision to scrap major design features because they can not be made accessible.

Building Accessible Kiosks in 3 Steps

1. If your website or application is WCAG compliant, it is very simple to make your kiosk application/deployment compliant.
2. Once the website or application is compliant, the kiosk hardware that supports accessibility must still be integrated/included.
3. Kiosk hardware & placement must be ADA compliant.

Simply put, kiosks need to follow WCAG guidelines and more in order to meet the minimum best practices for kiosk accessibility.

Picture the scene: You’ve managed to get to the shops, you’re excited you know what you want and you’ve got the money to pay for it. You’re in a wheelchair and there’s only steps, no ramp in to the shop. How do you feel? Pretty deflated at the very least I expect.

A lack of accessibility on the high street is costing retailers billions of pounds and is losing them valued custom from disabled shoppers. econsultancy.com carried out tests to see if the same was happening online and the results were surprising…

The ‘digital high street’ is a convenient way to shop without having to tackle the barriers disabled shoppers face in store. What better time than now to review the online accessibility of some popular UK retailers including Boots, Tesco, House of Fraser and more.

To evaluate a website’s online accessibility, they were audited against the Web Content Accessibility Guidelines from the W3C (WCAG 2.0).

A typical shopping journey was followed to understand how the retailers approached accessibility and they looked at things such as keyboard accessibility and screen reader compatibility. These are just some aspects that are considered major aspects of WCAG 2.0 Level AA, others include:

• Use of headings
• Alt text for images
• Availability of skip links
• Inclusion of a visible focus
• Access to forms
• Use of ARIA to provide greater context
• Access of pop ups / modal windows
• Colour contrast
• Content ordered logically
• Meaningful links that describe their purpose

All sites failed to meet Level AA of the WCAG 2.0 guidelines so disabled users would find it difficult to purchase a product. Half of the websites totally blocked users at certain points in their online journey.

Tesco and House of Fraser provided clear and consistent visible focus – a navigational technique informing the user of where they are on the page visually. Essential for sighted users who rely on visual cues to navigate with a keyboard.

House of Fraser highlight the selected navigation item with a pink underline, clearly detectable from the text around it.

Only half of the websites implemented ‘skip to’ links so keyboard and screen reader users could also share the privilege of skipping lengthy navigation menus and going straight to the main content. House of Fraser excelled here too. Joules’ skip links were designed to be hidden for sighted users but consequently, sighted keyboard users were unable to take advantage of this functionality.

All retailers were pretty good with use of alternative text with appropriate and descriptive alt tags on images allowing users with visual and cognitive disabilities to access the same content as everybody else.

Providing context to screen reader users is fundamental for those who are not able to visually group information or comprehend it’s meaning from how it’s been presented visually. All retailers at one point or another had links that did not make sense out of context such as Mothercare.com’s use of links such as ”remove” and “edit”.

Those unable to see the visuals that the links ”remove” and “edit” sit beneath would struggle to know what these prompts relate to.

Generally, retailers have a visual indication when sizes are out of stock but often there was no verbal notification that a size was out of stock, all sizes would be read out, implying they are available. A screen reader user would be unable to choose a product size, at which point they’d need to either give up or request assistance.

Online retail could be the ideal solution for those who suffer physical difficulties when shopping in store and most retailers had a reassuring accessibility statements full of good intentions but they need to act further on this by implementing WCAG 2.0 to significantly improve accessibility. They should also consult with accessibility and UX experts to fully understand the needs of disabled customers and the technical solutions required to provide accessibility.

If you want to find a digital agency with a background in web development, accessibility, usability, App design and build, feel free to get in touch with the friendly team at focusgov to discuss your project.

My tilted reflection stares back at me as I ponder whether I’ll ever get around to hanging this full length mirror up on the wall. For months it has been leaning there next to the canvas prints that long for a nail to sit upon, far away from my clumsy footsteps.

Realistically, that isn’t likely to happen until my toolbox pries itself from between the lawnmower and empty shoeboxes I’m convinced I’ll find a use for.

What I want is for someone to bring my toolbox to me, hand me the best tools for the job and show me how it’s done.

If monitoring and assessing the accessibility of your websites is your mirror to hang, I’m about to bring you your tools.

Whether you’re just getting in to the accessibility swing of things or you’re well practiced in making a website accessible, this responsibility can be very daunting. There are so many reasons a website could become inaccessible and they’re not always easy to keep on top of.

Here’s where the tool talk comes in! There are plenty of accessibility tools available online. The W3C publishes a list of these at https://www.w3.org/WAI/ER/tools/ Currently there are 88 tools displaying for me but I’ll ease you in gently with a Top 5:

Colour safe palette generator

Really nice site where you can create stylish and accessible colour palettes based on WCAG Guidelines of text and background contrast ratios.

http://colorsafe.co/

aXe Chrome extension

The free aXe Chrome extension is an accessibility testing tool that returns zero false positives. You can run audits in the browser and it will show all accessibility errors along with an explanation of the broken rule (from WCAG 2.0 and section 508) and the corresponding standard.

http://bit.ly/2a1W6oJ

Accessibility Checker

Accessibility Checker will scan your website for free, identify accessibility issues, and give you exact instructions on how to fix them.

AccessibilityChecker.org

AudioEye

AudioEye automatically tests for over 400 accessibility issues, fixes them automatically and continually monitors your website.

www.audioeye.com

Dashboard for automatic accessibility testing

This web dashboard automatically performs daily tests of web pages. Graphs help you track improvements and regressions over time. It’s especially useful for non-developers to see how your sites perform.

https://github.com/pa11y/dashboard

Accessibility visualisation toolkit

tota11y helps you to visualise how your site performs with assistive technologies. Great for those with no prior accessibility knowledge as it help you to visualise accessibility violations (and successes), while educating on best practices.

http://khan.github.io/tota11y/

The best tool though? User research. There’s no better way of finding what needs fixing than by watching someone navigate your site with the use of a screenreader or other assistive technology. Just like looking in a mirror, you’ll never be able to see what someone else does.

If you want to find a digital agency with a background in web development, accessibility, usability, App design and build, feel free to get in touch with the friendly team at focusgov to discuss your project https://www.focusgov.co.uk/enquiries/new.

This is a guest post by Maria C Lima and first published on mclinteractive.com

Website Accessibility

July 25, 2012. “About 56.7 million people — 19 percent of the population — had a disability in 2010, according to a broad definition of disability, with more than half of them reporting the disability was severe, according to a comprehensive report on this population released today by the U.S. Census Bureau”.

I have been reading materials, watching tutorials, writing accessibility code, and learned that it should be part of our strategy to make our website compliant with accessibility to allow people with disabilities to use the site.  This approach will not only help enormously people with disabilities, but also maximize the number of people using our website and promote our company as socially responsible.

Website Accessibility Considerations

If you would like to make your website accessible to all individuals, you should make the necessary adjustments to your website taking in consideration the following key items although you should consult the WCAG 2.0 Checklists for a complete set of guidelines:

1. Color Management. People with low vision have difficulty in differentiating colors. So color contrast will help them, or I should actually say will help everybody to better read and understand a web page. There are tools that analyze your web page and search for color contrast issues among others. As an example, search the Chrome Web Store for automated tools such as Wave or aXe.
2. Web Page Structure. Each web page should identify the language being used, and have a title and headings descending in size. Content should be structured to include header, navigation, main, and footer sections.
3. HTML Semantics. The inclusion of HTML5 in our code makes accessibility compliance much easier, as HTML5 includes tags, such as <header>, <nav>, <label>, <footer>, etc. which are self-explanatory. This approach reduces the use of Aria attributes, which prevents us from writing additional code. Nevertheless, there will be circumstances where we need to use Aria – please retrieve the latter link for more information.
4. Link Management. The links’ text must be clear and informative. You should avoid using key phrases, such as “Click Here”.
5. Text Alternatives. Elements such as images, which cannot be seen by visually impaired people, should include a text attribute – which is called ‘alt’ and describes the image – as an alternative to the image. You should also include a text alternative to video and audio.
6. Keyboard Operability. People motor impaired cannot use the mouse. Consequently, it is necessary to provide functionality via a keyboard, so the user can use the ‘tab’ key to navigate through your website.
   • Focus Management. We need to programmatically give focus to certain elements, so we can browse the website with the keyboard. As an instance, if a dialog box pops up, the user should be able to close it by pressing the ‘Enter’ key. In order to press the ‘Enter’ key, it is necessary to programmatically give focus to the ‘OK/Close’ button.

Website Accessibility Testing

In order to make your website accessible, it is important to invest time testing it. Hiring a person/consultant with disabilities to test your website should be a part of your company’s strategy.

Usually, I take the following steps to test a website:

1. Keyboard Functionality. I first test the web pages using the keyboard to make sure the elements are tabbed on a sequential order.
2. Testing on Screen Readers. Afterwards, I test the web pages on Voice Over, which is a screen reader for MAC computers. However, there are also screen readers for windows computers – please retrieve the latter link for more information.
3. Automated Testing: TENON / Wave / Axe. I then perform automated testing. I use tools such as TENON. The thought of making a website accessible made me always very anxious until the moment I first used TENON. The use of this tool simplifies the process because it does most of the work for us. This tool scans the pages, and provides a list of errors/warnings and suggests fixes. In addition, I use Wave and aXe. The Wave Chrome extension scans the web page and provides a detailed report on accessible elements and errors. aXe provides an analysis report.
4. Manual Testing. After the automated tests, I perform a manual test. I carefully look at the code page by page to add any other accessible markup, paying special attention to the following:
   • Page Structure and HTML5 Semantics
   • Buttons, Links, and Alternative Text
   • Focus Handling

   Usually, I need to add Aria attributes to the markup of certain modular widgets, such as dialog boxes, dropdowns, etc. This requires writing some JavaScript.

If you have any questions, please contact me at maria@mclinteractive.com. I’ll be more than glad to help you clarify any issue you might have or work with you to make your website accessible.