Accessibility is a part of WebExpo 2013

WebExpo Prague 2013 conference is going to take place next week and I am very happy that this year there is a series of talks on accessibility as a part of the programme.

There are three talks concerning accessibility:

• Universal Design & Accessibility in the Typing Experience: The Sound of One Hand Typing by Andrew Zusman
• Accessibility in High Contrast Mode by Jakub Tománek
• How to improve UX by implementing accessibility by Radek Pavlíček (yes, that's me ;)

According their descriptions, all talks look very interesting and worth seeing. And moreover, these talks also probably will bring a slightly different approach to accessibility. Andrew is going to talk about better typing experience for not only disabled typists, Jakub focuses on implementing pages suited for High Contrast Mode, and my topic could be summarized in one sentence - accessibility is for the majority, not the minority.

As in the previous years, because of the obligingness of WebExpo team, I and my colleague Roman will have an accessibility booth during the whole conference and we will be ready to help you with the accessibility issues. As usual, we will have some assistive technologies with us, so we can evaluate your website or app right on the spot.

Do you want to make a quick accessibility evaluation of your website or application for iOS or Android? Are you interested in assistive technologies for the blind and partially sighted users? Are you courious what benefits accessibility brings to all users? Then come and join us. We will be very happy to share our knowledge and help you to make your web or app as accessible as it would be possible. We will give our services free of charge during the conference for all WebExpo participants.

Of course accessibility is not the only reason why to attend WebExpo. There are a lot of interesting talks on agenda and many other activities including workshops, parties, networking, etc.

Still don't have your ticket? Then don't hesitate, buy your ticket now and come to WebExpo. I am looking forward to meeting you there.

Universal Access to the Content via HybridBook - CSUN 2013 session

CSUN 13 presentation on Hybridbook, which was lead by my colleague Svatoslav Ondra from The Support Centre for Students with Special Needs, Masaryk University, Brno, took place on Friday.

Hybrid Book provides a universal access to content for users with various disabilities as well as for users without disabilities, synchronizing audio, video, text media.

• Hybridbook is a digital publication format and also a couple of applications to read and author
• Its aim is to provide access to the content for readers with a limited perception of some of the information channel (e.g. the blind, the deaf, dyslexics and others)
• Hybridbook provides content in different types of media and ensure also their synchronization.
• Hybridbook 1: multimedia publication combining an electronic text with audio (made by human voice) supplemented by complex navigation apparatus. It must be read on computer, Hybrid Book Player is a native application, distributed on CD. This version was intended especially for people with visual impairement.
• Hybridbook 2: issued 2006, reader application migrated to online web app (because of easier maintenance). This version was based on HTML, JavaScript, Windows Media Player/QuickTime and also kept all functionalities and principles as well as synchronization with virtual cursors of screen-readers.
• HybridBook 3. Aim: present information with complementing records in the least possibly distorted form which enables:
  • perceiving visual text visually
  • perceiving text in Braille
  • perceiving via sound recording
  • perceiving in different languages (mainly in sign languages)
  Quick and easy navigation in the structure.
• Types of media: text, audio, video (mostly for sign language translations).
• More sources of the same media type - all synchronized, played at the same time or alternately.
• Incorporation of more complex objects (tabelar data, structured alternate form of graphics, mathematics expressions, footnotes).

• Primary target groups: blind and visually impaired users, deaf and hard of hearing users and users with learning deisabilities.
• There are two layers:
  • Main layer (contains the main document (text, audio, video)
  • Additional layer (contains extensional content to supplement insufficient information (can be hidden/shown, if shown it acts as a part of main layer)
• Media format:
  • Text: XHTML
  • Video: MPEG-4 (H.264), OGG (Theora codec)
  • Audio: MPEG-1 Layer 3 (“MP3”), OGG (Vorbis codec)
• Synchronization:
  • based on dividing content to synchronization units – the smallest building blocks (certain logically delimited passages)
  • storage of synchronization data is independent on storage of document/media data
• Reading the book: there is full media synchronization, complex navigation and highlighting of the passage being currently read in text. User can also mute on/off audio or video track, switch among them or reposition UI components.
• Hybrid Book Authoring Tool: automatic division into synchronization units, creation of all meta data and scenarios for multimedia preparation and import/export Daisy 3.
• Near future: web app for mobile platforms, native mobile app and possibility to read documents offline.
• Future prospects: improvement of additional layers which provides alternate content of complex objects, implementation of “native” navigation in tabular structures and implementation of math expressions.
• Online version is on www.teiresias.muni.cz/en

CSUN 2013 from my point of view

• Google Accessibility Update - CSUN 2013 workshop
• Responsive Design and Accessibility - CSUN 2013 Workshop

Google Accessibility Update - CSUN 2013 workshop

On Tuesday I attended the whole day workshop, called Google Accessibility Update, which was led by T. V. Raman and other at least 15 people from Google, including product managers of their core applications, internal accessibility evangelists and development staff.

I really love Google services - my primary browser is Chrome, I use Gmail both on desktop and mobile, have phone with Android, etc. And I am really glad what enhancements Google did during past two years in a field of their products accessibility. There is of course still what to improve, but the progress is amazing.

Workshop covered all the major Google products and services - Chrome OS, Drive, Docs Suite, Gmail and Android and give us an overview about state of the art in this field.

A lot of work is being put into the Chrome OS to provide additional support for blind users via ChromeVox. The only way to make accessibility better is to simplify it at every level.

Every user has different needs and we need to build a customizable interface that works for everyone.

Chromebooks are cheap, boot in under 8 seconds, hassle- and maintenance-free. Just sign in with Google account. All your stuff is in the cloud. Accessibility is built-into OS at setup; spoken feedback provided via ChromeVox, user can also enable other accessibility features.

Google is now running Chromebook Accessibility Trusted Tester Program for individuals from USA, who will be provided with a Chromebook with the expectation to be active testers. It is a pity that this program isn't also in the Czech republic - I would apply immediately ;-)

Gmail was originally designed for sighted users, better support for blind users is a matter of the last few years. Now there is a extensive support for ARIA labelling, new features are tested manually and there are also automated tests for regressions. Nowadays there is a good support for keyboard-only users - you can use arrow keys, N and P keys and Enter to navigate between and within regions.

Drive and Docs Suite accessibility is very closely related to ChromeVox. There are a lot of changes, for example keyboard interaction model in Drive is completely redesigned, focus management is improved or navigation itself is more consistent.

A lot of the keyboard accessibility features and new keyboard model is useful for people without disabilities as well (for example for me ;-)

New Accessibility for Google Apps were announced on this workshop.

Android brings completely unassisted setup, Jelly Bean 4.2 has accessibility shortcut, enabling to toggle TalkBack from anywhere using Power button. There is also a simple screen magnifier as a part of Jelly Bean 4.2 (triple tap to zoom in and interact while panning, triple tap and hold to zoom temporarily). This magnifier unfortunately does not magnify the keyboard.

In general, it is good to know that the best accessiblity experience on Android is with Jelly Bean.

A lot of practical and live demos were given by Google team members during the whole day - for example on Gmail, Google Drive on Android, Slides, Docs editor, etc.

Googlers were also asked a lot of questions. You can read them - together with answers and detailed notes - on Paul Schantz blog.

Big thanks to Raman and his team (also for the T-shirt ;)

Related to this post

• Making the cloud more accessible with Chrome and Android

CSUN 2013 from my point of view

• Responsive Design and Accessibility - CSUN 2013 Workshop

Responsive Design and Accessibility - CSUN 2013 Workshop

This week (thanks to my great employer - Teiresias Centre at Masaryk University, Brno) I am attending CSUN 2013 Conference and workshops in San Diego, California. There are great sessions on agenda of the conference. The first one was a workshop on Responsive Design and Accessibility by Hans Hillen from The Paciello Group.

This workshop is/was really useful and important for all who think that web is only desktop (it is not), focus mostly on visual design and ignore all mobile devices.

Here are some notes and comments which I made during this session.

• Mobile is not just phones, but all portable electronics (tablets, game consoles, TVs, ets.). It includes also native apps and of course mobile web.
• Mobile accessibility means making a website or application more accessible to people with disabilities using mobile devices. The basics are the same as on the desktop: alternatives, labelling, good structure, native controls, content order.
• Who we are talking about: 4 main user groups (vision, hearing, mobility, cognitive and learning), assistive technology users (screen readers, magnification), access services users (captions, subtitles, audio description), hidden disabilites (photo sensitivity, mental health), aging, temporary (broken wrist), cultural (language), technology (connectivity, particular SW and HW requirements), common ground between mainstream users and users with disabilities, empathy
• Often, we have images of people with extreme disabilities in mind (totally blind, amputees, wheelchair users, totally deaf, etc), but many of us have mild disabilities (e.g. people who wear glasses) or hidden disabilities.
• Constraints of Mobile Accessibility: small screen, small text size, small input devices and eyes-free usage, reliant on touch on handed usage, low light, connectivity and data limitations.
• Capabilities of a Mobile Environment: better integrated accessibility than desktop, location and direction, camera and augmented reality, touch screen, environmental awareness (light/dark conditions) -> a lot of new possibilites.
• Enabling Features and Innovations: app that helps color blind people identify colors, Apple’s Siri voice recognition, Google Voice’s voicemail transcription, Custom vibrations on iPhone and Android
• Two Main Interaction Methods: Explore by touch and Gesture navigation.
• Current Situation of Mobile Accessibility: iOS accessibility features and API are more mature, Android devices have some good accessibility features and Google are working to improve.
• Principles of Accessibility for the Mobile Web:
  • Use progressive enhancement
  • Use a responsive design approach
  • Use web standards as intended
  • Support native accessibility settings and assistive technology for your target platforms
• Mobile first: instead of building sites for desktop and degrading for mobile, focus on content and small screen then build up.
• Use web standards as intended: accessibility is already “baked in” (buttons instead of styled divs)
• Forms: using touch for inputing the content is difficult in general. Replace free input with more helpful controls. HTML5 input types bring Contextual keyboards in iOS/Android with useful buttons.
• Responsive web design (RWD) is a web design approach aimed at crafting sites to provide an optimal viewing experience—easy reading and navigation with a minimum of resizing, panning, and scrolling—across a wide range of devices (from desktop computer monitors to mobile phones) - definition from Wikipedia.
• Basically, responsive design means MEDIA QUERIES. Supported in all modern browsers (not in IE8).
• General accessibility rules still apply in responsive design! Follow WCAG 2.0.
• Responsive on Desktop. Very useful for low vision (or screen magnifier) users (it is not necessary to scroll horizontally).
• Color Contrast: as a responsive page is modified between responsive break points, foreground may overlap background differently.
• Hans prefers zoom over text-only resize over in page sizing controls.
• Reading Order Problem: in some cases, the visual order of content is rearranged, while the structural order is not.
• It’s fine to resize, reflow, filter and modify as long as the order of content stays consistent visually and in the document structure.
• ARIA is supposed to be supported on mobile devices as well.
• In some cases, a responsive switch may cause more than just a layout reflow.
  • Content can be filtered out.
  • Interactive controls may change into different types of UI (group of links may change into a dropdown button)
  • For a screen reader user it may not be clear that this change occurs
  • In this case - Notify user about it.
• Data tables: very difficult to make accessible. Possible solutions - allow users to switch to the original version of the table or let them choose which columns will be displayed.
• Responsive Design Can be confusing to inexperienced users, or users with specific expecations. Always allow users to switch to the default, desktop version of a site.
• Guidelines and standards: There is no one set of internationally accepted mobile guidelines and standards. Mobile Accessibility Guidelines by Funka Nu
• Make a test strategy: strategy by Henny Swan

Testing Mobile Accessibility on iOS

Workshop was really useful for me and although I know some presented topics very well, it gave me a comprehensive overview of the state of the art of this topic. On the other hand, I would really appreciate more practical examples such was accessibility of responsive data tables which was presented and discussed. I gave 4 stars from 5.

Thank you very much for this workshop, Hans.

How to measure font size on a web page

Web Content Accessibility Guidelines 2.0 methodology uses relative luminance algorithm for the evaluation of contrast. This algorithm is based not only on used colors, but also on size of text. The visual presentation of text and images of text have a contrast ratio of at least 4.5:1 for text size up to 18 point or 14 point bold or a contrast ratio of at least 3:1 for text size bigger than 18 point or 14 point bold.

It sounds logical and at first sight there are no difficulties. Especially in cases, when we work with text, size of which is defined in points. We launch for example Colour Contrast Analyzer, measure the values and we get the result. But what to do when the text size is defined in other units - em, pixels, percents...? In what case does the text have its size 18 point or 14 point bold? This is what we have to know to determine which value of contrast ratio (4.5:1 ar 3:1) is relevant for us.

Some, yet not an easy-to-use solution offers the large scale (text) definition from WCAG 2.0:

For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use.

This paragraph contains the answer to question how we can easily convert various units. But still we don´t know, how to easily measure size of a particular text where we want to evaluate its contrast.

In practice I use the solution based on add-on Context Font for Firefox and conversion table Convert em,px,pt and % in CSS. Because Context Font add-on measures sizes in pixels, it´s necessary to convert sizes 14 and 18 points to pixels. Then the visual presentation of text and images of text have a contrast ratio of at least 4.5:1 for text size up to 24 pixels (18 points, 1.5em, 150%) or 19 pixels (14 points, 1.2em, 120%) bold or a contrast ratio of at least 3:1 for text size bigger than 24 pixels or 19 pixels bold.

I realize that the values are rounded, but based on my own experience I don´t think that this rounding has any negative impact on the accessibility of the text.

Google has already started to take accessibility in mind. And what about you?

This Tuesday - due to invitation by Paul Kinlan and Filip Hráček (thank´s guys ;-) - I attended Google Developer Day in Prague. Paul gave a speech called Making Your Web Apps Accessible Using HTML5 and ChromeVox and my brief talk was a part of it.

Paul talked about the importance of keyboard navigation, labelling form elements, use native HTML tags, ARIA roles, states and properties and of course of use of ChromeVox to evaluate accessibility.

I mainly focused on two issues - Google effort to be more accessible for people with disabilities and cooperation of Google Chrome with common screenreaders such as JAWS or NVDA together with practical demonstration of it.

Google effort to be more accessible for people with disabilities

In the first part of my talk I mentioned some issues related to accessibility of Google services. Google search is fully accessible and people with disabilities have been using it for years. Android can also be accessible for the blind and even though there are things that still need to be done to reach full accessibility, there are a few blind users in the Czech republic who use phones with Android. For more information (in Czech) see www.blind-android.cz or pavelondra.posterous.com Survey on Computer Usage Patterns together with American Council of the Blind is another proof, that Google takes accessibility seriously and try to improve accessibility of its services, such as Google Docs and Google Calendar, where there are new keyboard shortcuts and some support for screenreaders.

The last topic in this part was our attempt to establish Accessibility Google user group as a part of Gug.cz. I hope that this group will start as soon as possible and wish Pavel Ondra to be a good leader of it.

Google Chrome and JAWS

The second part of my talk was dedicated to practical brief demo how to use Google Chrome with common screenreader - namely with JAWS. Now, blind users can use not only Windows Internet Explorer and Mozilla Firefox, but also Google Chrome for browsing the web. I demonstrated to the participants how to navigate the web page simply using JAWS features Headings list and Links list.

Many improvements still have to be made before Google services are fully accessible to the blind, but the enhancements that have already been done indicate a commitment to accessibility by Google.

In the end of my talk I truly appreciated Google for having started with accessibility and tried to persuade the auditorium of the importance of accessibility and motivated them - if accessibility is important for Google (and other big companies such as Apple or Seznam.cz), it should be also important for them.

A lot of questions after our session showed me that it was good that this session was a part of this year GDD.

Are you interested in accessibility? Me and my colleagues are ready to help all of you who want to make their websites or services accessible ;-) Feel free to contact us.

Google and accessibility

View more presentations from Radek Pavlíček.