Digital A11y

sathish kumar

About sathish kumar

I am a Senior Accessibility Consultant, working at Deque Software PVT LTD. My experience spans for seven years across domains such as travel, education, eCommerce Healthcare etc. bringing digital accessibility into websites, mobile web, Android and iOS native apps, PDFs, Word documents and PowerPoint presentations. I have presented papers at international conferences; spoken at different meet-ups and forums and mentored teams for a11y competitions.

Understanding SC 3.1.2 Language of Parts

Last Modified on by Leave a Comment

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA).

This success criterion requires that the contents written in multiple languages on the same web page has the human language defined in a programmatically determinable way. In other words, where the default language of the page is, say English but the page has phrases, sentences, paragraphs or passages from any other language, then the secondary language of such texts must be programmatically determined.

Exceptions

  • Any words that are adopted into the default language and that is part of a phrase or immediately surrounding text need not meet this criterion
  • Technical terms can be ignored.

Benefits

  • Visual browsers would be able to display correct characters for the language of parts and change the reading order for the languages that have right to left reading
  • Braille translating software would be able to provide correct Braille characters and contractions
  • Screen readers would be able to switch to apt pronunciation rules
  • Traditional browsers would be able to process the texts aptly
  • Machine based translation technologies would be able to translate the texts from one language into another when there is a change of language
  • In the modern browsers, when such secondary language texts occur, users would be able to look up the meaning using a dictionary.

Points to ponder

  • Ensure to use appropriate language code (lan=”fr”) wherever the text is in other language
  • Ensure appropriate language token is used in the lang attribute (lang=”pt-br”).
  • Beware of the exceptions too.

References

Understanding Success Criterion 3.1.2

Continue reading Understanding SC 3.1.2 Language of Parts

Understanding SC 3.1.1 Language of Page

Last Modified on by Leave a Comment

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

This success criterion requires that each web page of a site has its default human language programmatically defined. This, according to the Internationalization best practices plays a critical role in determining the default text-processing language. Apart from this, this is a key factor for screen readers to switch to the correct reading language, load correct pronunciation rules of language variations. Traditional browsers can render the text correctly and visual browsers can load characters and scripts appropriately. Thus language of page helps people with disabilities understand content in a better way.

Points to Ponder

  • Ensure each page of your web site has lang attribute
  • Ensure the language code is correct
  • Use appropriate language tokens in terms of language variations like lang=en-us” for English in US and lang=”en-uk” for English in Britain.

References

Understanding Success Criterion 3.1.1

Continue reading Understanding SC 3.1.1 Language of Page

Understanding SC 1.1.1 Non-text Content

Last Modified on by Leave a Comment

1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)

  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
  • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
  • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

This success criterion requires that any
non-text content that includes active images (imagelinks), area maps,
informative images, complex charts and graphs, 
CSS images, decorative images, input image controls, CAPTCHA and audio
and video contents must have text alternatives. Out of these non-text elements,
prerecorded audio and video, live audio and video are specifically handled in
SC guideline 1.2.

What types of images are we talking about here?

We are talking about:

  • Image links: images buried inside anchors and redirect you to destinations
  • Area maps: Areas that trigger different actions/different destinations
  • Informative images: images that are meant to inform users
  • Purely decorative: images that are here to decorate your pages and appeal to users
  • CSS images: Self explains Input type=”images”: That submits a form
  • CAPTCHAs: Confirms whether we are human
  • Audio and video file images: Images that play audio or video contents
  • Complex charts and graphs: explains themselves

How are we to fix them?

WCAG’s sufficient techniques are not exhaustive as new ways would emerge. Yet, we suggest you have a look at them.

But here are a few of the for you:

  • Alt attribute: Works on img tags; let the values be meaningful and impregnated with equivalent purpose of the image!
  • Role=”img” and aria-label: works on anchors, CSS images
  • Title attribute: Works on imagelinks
  • Role=”presentation” or alt=””: Works on decorative images
  • Value or name attribute: Works on input type=”image”.
  • Plane text on the page: Every media content would accept and would users far and wide.

Points to Ponder

  • Always provide alternative options like audio or OTP (one time password) for CAPTCHA.
  • Always provide textual summary or description for complex charts and graphs apart form shot alt text.
  • Always use title attribute for additional info while using alt attribute in image links.

References

Understanding Success Criterion 1.1.1

Continue reading Understanding SC 1.1.1 Non-text Content

The WEBAIM One Million and The Accessibility Maturity of the Web World

Last Modified on by 2 Comments

Laws are in place; policies are published; subject matter experts are increasing every day; commercial and non-profit organizations are auditing, consulting and certifying. All are towards the one thing called web accessibility advocacy. Given these factors in 2019, has the accessibility of websites matured? Let’s find out!
The WebAIM One Million
In as recent as February 2019, WebAIM at www.webAIM.org published a study that specifically focused on evaluating the accessibility of one million home pages of a million sites mentioned in Majestic Millions List. This study was conducted using WebAIM’s Wave automation API and other tools. Despite automation tools being able to detect only 25% of accessibility errors as claimed in the study, the facts and the results are quite striking and interesting.

Interesting Facts from the Study

As mentioned earlier, the study used Wave automation API to detect accessibility errors based on WCAG 2.0 AA conformance. The study chose the home pages as they are ‘Gateway into the sites’ and a home page can tell you a lot of the rest of the site.
When it comes to WCAG failures, here are the results in short:

  • 85% of the home pages fail color contrast
  • 68% pages fail missing alternative text for images
  • 58% fail empty links
  • 52.8% of pages fail missing form labels
  • 33.1% pages are missing document language
  • 25% of pages fail empty buttons.

The facts do not end here. The study predicts that the users with disabilities would encounter error in one in every 13 elements that they engage with in the home pages themselves.
Further narrowing the results, the pages were categorized using their domains and thus narrowing down to the countries. In this, sites with .gov, .edu, .us which are affiliated to the federal government fair better as they are monitored continuously. .org fairs much better than .com(s). Also, the study suggests that the sites from countries like Germany, Japan, Netherlands, Australia and Canada stand out better than their counterparts like Russia and Italy.

ARIA

In general, the use of ARIA outpaces the use of native HTML elements like images and headings. But this doesn’t mean that the home pages are accessible. On the contrary, the home pages that use ARIA extensively average 11.2 more detectable errors than their counterparts. This is not to blame the presence of ARIA but the misuse or the abuse of it.

Conclusion

All in all, the study presents an abysmal state of the web accessibility maturity of the web world. The haunting fact is that 97.8% of home pages have detectable errors which are likely to be WCAG 2.0 failures. If this the state that faces us just out of automation, one could imagine how it would be if the manual test results come out.
The fact that 85% of pages fail color contrast suggests that the designers and style guide creators never concentrate on readability and viewability of their home pages which is far from accessibility. Then there are other factors like missing alternative texts, meaningless alt texts, unstructured headings, keyboard navigation and above all the use of ARIA replacing the native HTML mark up. This concludes that organizations are not yet ready to bake in accessibility in their web pages, web apps and their products. Even if they do so, the designers don’t design with accessibility in mind; further, developers don’t use semantically appropriate language markups; testing for accessibility errors is not part of SDLC and to top it all all of these entities lack the awareness of accessibility itself.
To conclude, the woods are not lovely but dark and deep. In the maturity of accessibility, there are miles to go before all of us sleep!

Read the complete study here: WebAIM Million

Related Articles

Continue reading The WEBAIM One Million and The Accessibility Maturity of the Web World

Axe Enters into new forays

Last Modified on by Leave a Comment

If you ever wonder when the a11y community would have a standard rule set for native Android and iOS apps, well, you may rejoice now!
In a recent joint press release at CSUN 2019, Deque Systems and Microsoft have announced their partnership to release Axe for Android and iOS. As Axe for native apps are going to provide a standard ruleset for native a11y testing, it is open source too. Further, this move enables the entire accessibility community to review, modify and come up with innovative a11y tools in the days to come.
The news does not end here. Adopting Axe into its fold, Microsoft has gone ahead to create a powerful a11y testing tool Insights. Now, Microsoft also has announced that its a11y tools based on axe-core named Axe for Windows as open source. Both these announcements have brought the mission of accessibility one step closer with the powerful contribution from the community.
Axe has evolved to be adopted by many tech giants like Google and Microsoft as part of their accessibility suite. Now that Axe for Windows and Axe for native apps are seeing the day light, what with Microsoft and Deque joining hands to collaborate alongside the community, let’s wait and see how these unfold new tools that make building accessible apps and websites easier and robust!

Continue reading Axe Enters into new forays

WebAIM’s Survey of Low Vision Users #2: What do we make of it?

Last Modified on by Leave a Comment

Just as everyone and their experience are not the same, so the persons with disabilities and their experience too. So when we talk about the low vision users, every user with low vision, his/her disability characteristics and the experience in the physical world and the digital world are so dynamic and unique.
In this context, WebAIM’s Survey of Low Vision Users attains its significance by connecting all the dots of users with low vision. This is a follow-up September 2018 Survey which was preceded by the March 2013 Survey.

Users’ Demography

In a total of 248 respondents, respondents from the age group of 0-21 are just 3.7%; 21-40 are 32.9%; 41-60 are 44.3% and 61 and older are 19.1%. Even though the highest of all the age groups is the 41-60, the disability is not because of the aging factor. This is categorically proclaimed by the fact that only 9.8% respondents indicated that their disability is due to the aging factor.

Level of Vision

With the level of vision determined by the impact in using a computer without assistive technology, the result shows clearly that the low vision users who have ‘Very Poor’ vision are high in number. This indicates the use of assistive technology among low vision users is rising as their vision deteriorates.

Types of Visual Impairment

This is clearly a complex topography as no one type is predominant among low vision users. While visual acuity (sharpness and clarity) ranks high with 75%, other type (user specific) gains the low rank with 18.1%. Light and glare sensitivity gains 61.3%; limited field of vision gains 48.8%; high contrast sensitivity gains 46.8%; color vision/color blindness gains 19.8%. The survey indicates that there is a combination of multiple impairments in majority respondents, the surprise element is that the color blindness/color vision as a single impairment is about only 4%.

Operating Systems, Browsers and Internet Proficiency

In the computer operating system side, Windows registers a 56% use among the respondents, Mac OS10 registers 16.5%. The notable fact is that the use of Apple’s OSX has seen a 2.2% rise from 14.3 to 16.5 in these years, Windows has seen a drop of 16.2% from 72.2% to 56%. In terms of mobile Operating system usage, Android is up from 2.3% to 5.6% and iOS is up from 14.3 to 18.5%. This could also indicate the usage of mobile devices is gaining its momentum among low vision users.
In the browsers usage, Chrome tops with 37.2%, Safari and Firefox follow with 21.8% and 21.0% respectively. Microsoft’s Intrnet Explorer and Edge have been seeing fall.
With regard to internet proficiency, the signs indicate that most of the respondents are internet users where 69.8% are advanced users.

Devices

When it comes to desktop/laptop/mobile devices, desktop/laptop is preferred over mobile devices. This could be attributed to the preference for larger screens.
When it comes to mobile devices, iOS devices top the chart with 64.3% followed by Android devices with 21.8%.

Assistive Technology

Screen readers, screen magnifier softwares or system settings, browser zoom controls, browser text sizing settings, high contrast mode or settings, browser seting to change colors, custom style sheets, tools that highlight text as it’s read, and other options like reader settings in the browser are the popular assistive technology widely used by low vision users. There is no one particular assistive technology that tops the chart though magnification scores 48.4%. It is also important to note that the majority use more than two assistive technology (68%) while some (23%) use four or more assistive technology.

Viewing and reading preferences

While 54.1% respondents use some type of high contrast mode, the most preferred mode is the white text on a dark background. When it comes to applying custom styling, changing the font size tops with 36.7% followed by changing the background/text color with 18.5%. Other custom styles that users prefer include changing font family/font face, font weight/boldness, line height/spacing, letter or word spacing, spacing around paragraphs, headings etc.
With regard to font types, most of the respondents prefer Sans-Serif (53.5%). With regard to magnification level, many prefer 200% to 400% (23%) which falls under the same value WCAG documents in its user study and in Success Criteria relevant to resize and reflow.
Users prefer OS level magnification settings with 45.1% while only 19.3% prefer ZoomText. The rest of the magnification software take a back seat.
When we talk about the reading and viewing preference on a mobile device, 83% people use the accessibility settings that include screen readers, magnifyers and large text.

Screen readers and Voice Assistants

In the desktop/laptop segment, many users (41.1%) don’t use a screen reader while a considerable number of users still use NVDA, JAWS and VoiceOver. Zoom Text usages has been decreasing over the years.
In the mobile devices segment, VoiceOver is being used the most with 43.6% followed by TalkBack with 6%. However, as many as 41.9% users don’t use any screen readers.
There is a mixed response with regard to voice assistance usage. While 25.3% users don’t use any voice assistants at all, 27.8% users use voice assistants very frequently.

Other Factors

Keyboard users are still at large with 31% of users use it always while 29% use often. Heading navigation is not preferred by many users as they may prefer tab navigation and they may not be using screen readers too.

Progress of Web Accessibility

While as many as 45.4% respondents have indicated that web accessibility is neither progressed, nor deteriorated, 34.8 users feel that web content accessibility has improved more. The response for the social media accessibility also indicate that there is a considerable improvement with 51.1% responding that it is somewhat accessible. But the fact that there is still the abandonment of reading by the low vision users (27.6% indicating that they abandon reading sometimes in a week) raises concerns as it stresses the need for more accessible web.

Conclusion

The sheer number of visual disability types, accommodations and preferences themselves tell us that one design doesn’t fit for all. As the low vision users still depend on their visual abilities – in whatever condition it is in, make adjustments and accommodations to consume content, shop, get entertained and do their daily professional tasks, it is high time the web designers take all the users into account when they design their sites and digital products. The design with its visual aspects must be flexible, accommodative and allow for user customization in order to achieve the high inclusivity. Only then, we would see the high number of respondents who would proclaim that the web is inclusive and accessible. It is not only the task of the AT vendors to help achieve this. Everyone in the world of internet must pursue this never-ending quest.

References

To read the complete result of this survey, click here.

Continue reading WebAIM’s Survey of Low Vision Users #2: What do we make of it?