1.4.13: Content on Hover or Focus

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true: (Level AA)

  • Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
  • Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
  • Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.


The common implementation of navigation menus shows the submenu on mouse hover. In most cases the submenus are not focusable by keyboard alone. Such implementations make the screen reader user even more frustrated as they are not aware of the display of new content.

Similar instances are quite common with display of tooltips or other information when user hovers the mouse pointer, shows a status message or an error message. Success criteria 1.4.13: Content on Hover or Focus addresses such critical problems.

People with low vision who depends on magnifier, those who have the habit of using large cursor benefit from this success criterion. Similarly people with low vision and cognitive challenges who need more time to identify the additional content on the screen benefit from this success criterion.


Conditions to satisfy for 1.4.13: Content on Hover or Focus

To ensure that the content displayed on mouse hover or focus is accessible, content developers must ensure the following 3 requirements are satisfied.


When a tooltip or additional content is displayed on mouse hover, the newly displayed content should not obscure the content read by the user. Users who depend on magnifier will have tough time if the newly displayed content overlaps the currently reading content. The methods recommended by the working group to solve this problem are,

  1. Place the content near the triggering element in such a way that the newly displayed content does not interfere with the existing content. The newly displayed content can be overlapped on a white space or decorative images.
  2. Allowing the user to dismiss the newly displayed content without moving the pointer away from the current content. Using escape to dismiss the content.
  3. Providing a close button in the newly displayed content that enable the user to dismiss the content but will not be ideal in situations where the content displayed is away from the user’s magnifier viewing region.



The second condition of this success criteria is to ensure that the newly displayed content must be hoverable. This also implies that the newly added content should be available near to the triggering element so that the user can directly hover from triggering element to the newly displayed content without the content gets disappeared. In case the content is large enough that the user has to move the focus from triggering element to the newly displayed content to accommodate the magnifier. This also helps the users who may have large cursor option set in their system settings or those who benefit from mouse movement with screen reader in use.


This condition of the success criteria talks about the adequate time for the user to read the newly displayed content. How long should the newly displayed content available for the user? Below are the recommended cases to satisfy this condition.

  1. The user removes hover from the triggering element. This is the typical user experience.
  2. When condition 1, dismissable is met.
  • When the newly displayed content becomes invalid. E.g. the tooltip that shows the agent is busy in a chat client and as soon as the agent becomes available the displayed content becomes invalid, so the content can be disappeared.

Exceptions for 1.4.13: Content on Hover or Focus

  • The visual presentation of the additional content is controlled by the user agent and is not modified by the author. Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute.
  • Modal dialogs are out of scope for this success criterion as they need explicit keyboard focus.

1.4.13: Content on Hover or Focus is a WCAG 2.1 success criterion.



NVDA 2019.1 is released, Download and What’s new

NVDA the free Windows screen reader by NVAccess released the next and first version for 2019 i.e. NVDA 2019.1. The release includes few new features, bug fixes and developer enhancements.

What’s new in NVDA 2019.1?

Highlights of this release include performance improvements when accessing both Microsoft word and Excel, stability and security improvements such as support for add-ons with version compatibility information.


  1. A new Advanced Settings category has been added to NVDA’s Settings dialog, including an option to try out NVDA’s new support for Microsoft Word via the Microsoft UI Automation API.
  2. NVDA no longer automatically loads custom appModules, globalPlugins and braille and synth drivers from the NVDA user configuration directory. This code should be instead packaged as an add-on with correct version information, ensuring that incompatible code is not run with current versions of NVDA.
  3. In Mozilla Firefox and Google Chrome, browse mode now reports the selected item in list boxes and trees.
    1. This works in Firefox 66 and later.
    2. This does not work for certain list boxes (HTML select controls) in Chrome.
  4. When moving by character in plain text controls (such as Notepad) or browse mode, 32 bit emoji characters consisting of two UTF-16 code points (such as 🤦) will now read properly.
  5. When tabbing or using quick navigation in browse mode, legends on tab panels are now reported more consistently.
  6. Fixed a rare browse mode crash in Firefox.
  7. NVDA no longer fails to report the suggested contact when entering addresses in new messages in Outlook 2016.
  8. In Mozilla Firefox and Google Chrome, switching to focus mode now works correctly for certain list boxes and trees (where the list box/tree is not itself focusable but its items are) .
  9. In Mozilla Firefox and Google Chrome, empty alerts are no longer reported.

A complete list of improvements, changes and bug fixes are available at What’s new in NVDA.

Download or update to NVDA 2019.1

Visit the NVDA download page for NVDA 2019.1. If already have an older version update to the latest version.

updating to NVDA 2019.1

  1. Press NVDA + n to open NVDA settings.
  2. Navigate to Help by pressing down arrow until you hear Help.
  3. Press right arrow to move into the help menu.
  4. Press down arrow until you hear Check for updates.
  5. Press enter Check for updates and follow the onscreen instructions.

NVDA is an open source and free screen reading solution for Windows operating system. Support the cause by donating to the NVDA project.

Magic tap, an accessibility feature in IOS

Every mobile app will have one task that is highly used, magic tap makes it easy and quick for voiceover users.

On your IOS device with the phone app, you want a simple gesture to answer and hang the call, play or stop the music on the music app, take a picture on camera app Magic tap the accessibility feature allows you to do it real quick when voiceover is switched on.

What is a magic tap?

A magic tap is a voiceover gesture available on most of the IOS devices. This gesture performs an often-used or most-intended action quickly.


How will magic tap work?

The gesture assigned to magic tap is two finger double tap. For instance go to music app on your IOS device and use two finger double tap gesture and the music starts playing and do it again the music stops. This is true when voiceover is switched on. You can try it even on camera app to take a photo. This gesture is added to these feature in few apps by default on IOS.


Is magic tap available on all the apps?

No, magic tap is not available on all apps at all times. For example in the phone app, this gesture can answer or hang-up the call, but if no call is currently running magic tap don’t do anything on the phone app. It can also so happen that all the apps does not require this gesture Developers can also add a magic tap for their app. Apps like twitter have got a step forward and allowed the twitter users to choose the action they like for twitter.

Deciding the action for magic tap on your app

What’s the most common action performed on your app? Creating a new post on a social app, bring up the recent orders on a booking app, record a voice message or invoke dictation on a instant messenger could be some examples of frequently used tasks.

How to add a magic tap for my app?

The magic tap feature is available in IOS 6 and above.

Declaration: func accessibilityPerformMagicTap() -> Bool

Know more about magic tap on apple accessibility developer guide.

Mobile Accessibility User Survey

Mobile accessibility user survey aims at collecting the experiences and preferences of users with disabilities who use mobile devices for their day to day activities. Mobile apps have a vital role in lives of people in this 21st century. From checking your emails, booking travel, managing your activities, social media, reading news, paying utility bills and many more activities are done just by having a smart phone and internet connectivity.

Are these mobile apps usable for everyone regardless of their abilities? Lately we understood that people with disabilities face several challenges using these mobile apps. It is also clear from our observation that different users have different challenges and each of their preferences are different.

Through this mobile accessibility user survey we want to understand the most common and critical accessibility challenges, research on the quick, consistent and reliable solutions for those challenges. Further we want to publish a white paper quoting some facts and guiding mobile app developers, designers and businesses in creating the user friendly apps.

Please fill in this mobile accessibility user survey by 25th April, 2019. Reach us at hello@maxability.co.in should you have any questions or difficulty submitting the survey. Share the survey within your community for us to have maximum participation that leads to more robust and powerful information on mobile accessibility.

Note: We are currently restricting this survey only to the users with disabilities who are impacted with the accessibility of mobile apps and friends / close acquaintance’s of people with disabilities who have the visibility to the mobile usage of persons with disabilities.

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 that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.


People with low vision possibly jump between the lines while reading a paragraph of content, sometimes even difficult to recognize the spacing between characters, words, lines and perhaps paragraphs. People who have dyslexia also need sufficient differentiating space between the content to read quickly.

This success criterion 1.4.12 text spacing ensures that the users may want to use user defined style sheets, browser plug-ins or bookmarklets to increase the space between characters, words, lines and paragraphs. While increasing the space, users should not face difficulty because of content cut-off or content overlapping.

Any responsibility for developers/ content authors?

1.4.12 Text Spacing does not specifically call out for any author responsibility. However, the author should ensure that the user defined styles are obeyed by the content whatever the form in which the text spacing is set by the user. In addition when the user sets text spacing as specified in this success criterion, authors should ensure that the content is not cut-off or overlapped making reading experience even more difficult.

User responsibilities if any?

Users may want to increase the text spacing that may be comfortable for their reading experience. The success criterion 1.4.12 Text spacing have the following boundaries.

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

Any content cut-off or content overlap beyond these boundaries is not a failure under this success criterion. User may even choose one or more or all of the said styles. In some languages few of these requirements may not be applicable such as content in Japanese that do not have word spacing.

Exceptions of 1.4.12 Text Spacing

  • Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.
  • PDF as it is not implemented using markup.
  • Video captions embedded directly into the video frames and not provided as an associated caption file.
  • Images of text.

Note: Canvas implementations of text are considered to be images of text and are exempted from this success criterion.


Related Links


Update on CAPTCHA Accessibility! W3C need your inputs

Do you want to take part and provide inputs to the most critical digital accessibility problem, inaccessibility of CAPTCHA? Here is an opportunity for you.

Overview of inaccessibility of CAPTCHA

CAPTCHA accessibility is one of the most tricky and long existing problem for digital accessibility. It is a known fact that having only one CAPTCHA model on the web page will leave certain other disabilities and hence often websites try providing at least two modes. Still the existing CAPTCHA models leave away certain user groups.

5 years ago, I wrote an article stressing the need of Captcha accessibility and different options then available. Google’s recaptcha was introduced few years back and the feature was used by many websites. Many other options available in the market are often un-noticed. This draft by W3C Accessible Platform Architectures (APA) Working Group along with Research Questions Task Force drafted a publication. This draft publication  is out for public inputs on February 14th, 2019 and is open until March 24th, 2019.


Why is inaccessibility of CAPTCHA important?

WCAG 2.0 and WCAG 2.1 success criteria 1.1.1 non-text content specifically refers to CAPTCHA. So, adhering to CAPTCHA accessibility is equally important. On the other hand because of inaccessible CAPTCHA on websites many users cannot signup, login, book tickets and cannot use many important functionalities of the website.


What’s the update on  CAPTCHA accessibility?

In follow-up with the widely accessed publication on W3C website, the Accessible Platform Architectures (APA) Working Group, published a second draft update to the W3C Note “Inaccessibility of CAPTCHA“. The team tried documenting every possible solution available to solve CAPTCHA. This draft is out for public review and seeks your inputs. This process will ensure that the document captures as many options as possible and is as complete as possible.

To make the review process comfortable W3C have shared the following questions that may be helpful while providing your inputs.

  • Does this document fully capture current problems with CAPTCHA and related systems?
  • Are there other CAPTCHA approaches that should be added?
  • Are there concerns for certain categories of persons with disabilities that remain unaddressed or insufficiently addressed in this document?
  • Are you aware of relevant research or technological development in this area we missed?
  • Have we sufficiently addressed CAPTCHA’s problems with I18N?
  • Are issues of privacy and security appropriately addressed?
  • Have we mis-characterized any technology we discuss?

How to provide your inputs

Thoroughly read through the document inaccessibility of CAPTCHA and share your inputs.

To comment, file an issue in the W3C apa GitHub repository. If this is not feasible, send email to public-apa@w3.org (comment archive). Comments are requested by 24 March 2019.


Writing an Accessibility Statement for your organization

Having an accessibility statement on the website shows your commitment towards persons with disabilities. With the increase in awareness on the need of inclusive  digital content, either you have a website or a mobile app, showing your commitment towards accessibility is important.

While having relevant information on an accessibility statement acknowledges the commitment towards accessibility and improve the brand image of your business,  providing irrelevant or false information may damage the reputation.

Is it important to have an accessibility statement?

While showing your commitment towards accessibility and persons with disabilities, accessibility statement provides you an opportunity to speak about the effort you have put in for the commitment. In addition you can briefly talk about the accessibility enhancements, accessibility standards followed and the supported assistive technologies, browsers and operating systems. The accessibility statement will also give you an opportunity to be open on any inaccessible content and can share your justification or alternate methods to use such content. This statement also opens up the door for the users to share feedback which of course is the best input you can ever get.

What’s include in the accessibility statement?

The Education and Outreach group of world Wide Web Consortium WAI developed an interesting accessibility statement generation tool. According to this the following can be included as part of your accessibility statement

  1. Basic information: A brief information about your business, accessibility standards applied and contact information for feedback.
  2. Your efforts: In this section you can explain the efforts you have taken and will be taking in the future to make the website accessible. Further you can also explain the long term goals you have for the website or mobile app accessibility.
  3. Technical information: This section can explain about the technology used such as HTML, CSS JavaScript etc and how you used them to make your application accessible. This will also give you an opportunity to talk about the compatible assistive technologies, browsers and operating systems and  any known compatibility issues. You may also document the evidence for your accessibility claims such as link to an accessibility report, external quality check information, certifications if any.
  4. –Approval and complaints process: I believe it might not be possible in many situations but It will be worth mentioning the team within the organization that approved this statement. In addition if the organization have any complaint hierarchy for accessibility, this is the place to provide it.


Writing the accessibility statement

Writing the accessibility statement is often same as writing any other content of the page, however the Education and Outreach group of W3C have developed a wonderful tool to generate the same. All that you need to do is to provide as much information as you could on the tool and create the accessibility statement. Download the HTML file after the preview and update your website.

Have a look at the Accessibility statement generating tool and update your website today.

Sample accessibility statements

Here are few sample statements generated from the tool.

Maxability example

Minimal example

Complete example

WCAG 2.1 color contrast analyzer

During June 2018, W3C WAI recommended the new accessibility standard Web Content Accessibility Guidelines 2.1 i.e. WCAG 2.1. Along with many new success criteria specific success criterion is added that speaks about color contrast for non-text content. While the existing 1.4.3 contrast (minimum)  and 1.4.6 contrast (Enhanced) still exist.

1.4.11 Non-text contrast

The success criteria says

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

User Interface Components

Visual information required to identify user interface components and states, 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.

Read more about 1.4.11 non-text contrast.

Most of the color contrast testing tools still show the WCAG 2.0 success criteria only. The new color contrast analyzer from The Paciello group can identify the contrast between the non-text content and their background and analyze the conformance including the new WCAG 2.1 success criteria.

About the WCAG 2.1 Color Contrast Analyzer

The new WCAG 2.1 color contrast analyzer was released late 2018 to match with the new success criterion 1.4.11 Non-text contrast. The tool was rebuilt from the scratch using electron. Interestingly most of the features of the tool are accessible by screen reader and keyboard. More keyboard access is added in the future release I believe. Since the user interface is built with HTML elements, using the tool is usable and accessible compared with the old version of CCA.

Screenshot of color contrast analyzer showing the result as 6.71: 1 with foreground color #801243 and background color #d2d2d2
Screenshot of color contrast analyzer with color names foreground green and background red selected and contrast ratio detected as 1.3: 1. Failed for all the 3 success criteria.

Features of WCAG 2.1 Color Contrast Analyzer

The most important feature I believe is that allows the users to pick the foreground color and background color from the existing web page, design or any other digital format and find the contrast between them. This feature allows to identify the accurate contrast for existing UI. The other interesting features of the validator are

  1. Option to provide the foreground and background color values in any of the following formats to identify the contrasts in various WCAG 2.1 success criteria.
    • Names: blue, grey, orange, …
    • RGB: rgb(200,200,200), rgba(200,60,60,0.3)
    • HSL: hsl(360,100%,50%), hsla(360,60%,50%,0.4)
  2. Alpha transparency support for foreground colors.
  3. Color blindness simulator.
  4. Option to switch foreground and background colors.
  5. Support to WCAG 2.1 conformance checks.
  6. Available for both Windows and Mac OS.

Where can I download WCAG 2.1 Color contrast analyzer?

The new CCA tool is developed by The Paciello Group. Additional information of the tool can be found at the  Color contrast analyzer page. The code and other information including Mac and Windows versions are at download CCA page.

Download and run the exe file to install. Once the tool is installed it will create an icon on desktop to start using it.

Switch access on Mobile

Switch Access allows the users with dexterity impairments to use their mobile device without touching the screen. Because dexterity impairment can limit individuals strength, speed, endurance, and

coordination. Persons with such difficulties cannot use their fingers to interact with a touch screen. To overcome such ability mobile operating systems have built in assistive feature called Switch access. Switch access is an assistive feature available both in IOS and Android operating systems.

Types of Switch Access

Though switch access is a built-in feature in both Android and IOS devices, to use it an external switch device is required or a feature within the device can be set as a switch. Connecting the switch access is discussed later in this article with individual operating systems.

Switch Access in Android

Switch access can be connected to external switch device keyboard or the hardware keys of volume can also be mapped to the switch access. If an external device is used then  connect it to the device either via USB or a bluetooth.

Note: Once you connect the switch device the onscreen keyboard will be hidden automatically. Users need to re-enable the keyboard from the settings > language & input.

Connecting Single, double or group switch controls

Navigate to Settings > accessibility > switch access > settings

Auto scan : When you are setting up single  switch control,  select auto scan In the switch access feature. Various options are available in auto scan, after selecting the required options tap on auto scan on.

In this method the control moves one after the other item on the screen. User is expected to select it by pressing the switch again.

Step Scan : Step scanning should be selected when you have two or more switches. While one switch navigates through the screen the other switch selects the item.

Group selection: Even a group selection can be enabled when there are two or more switches. Group selection option enables users to navigate and select items on the screen faster than auto scan and step scan.

Here are the setting up steps for switch access on Android.

Using switch Access on Android

Switch Access on IOS device

Similar to switch access in android, IOS also allow external devices to be mapped with the device While the external switch control need to be connected to the IOS device before activating it as a switch. In addition the screen or front camera  can be set as a switch control.

  • Screen: Tap the screen to use a switch or press and hold.
  • Camera: Move your head to use the iPhone front-facing camera as a switch. You can use the camera as two switches: One when you move your head to the left, and the other when you move your head to the right.

Connecting the switch controls

Once you decide which control to use for switch access,

  1. Go to Settings > General > Accessibility > Switch Control > Switches.
  2. Tap Add New Switch and choose a source.
  3. Follow the onscreen steps to choose how you want the switch to work.
  4. Remember to turn on Switch Control, so you can use your new switch.

Here are  the steps to setup and other features for switch access on IOS.

Connecting and using switch access on IOS

See also 5 ways of typing with voiceover

1.4.11 Non-text Contrast

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

  • User Interface Components
  • Visual information required to identify user interface components and states, 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.



1.4.11 Non-text contrast is similar to 1.4.3 Contrast minimum. People with low vision will have tough time reading and understanding the content that has poor contrast. As regular text requires 4.5 : 1 contrast between the text and background, large text requires 3 : 1 ratio between the text color and it’s background, in WCAG 2.0 non-text elements such as actionable controls, focus indicators, selection identifiers are not specifically mentioned to meet the contrast requirements. In WCAG 2.1, these active controls i.e. buttons and form fields, text on action controls, visual effects such as focus indicators,  selection identifiers, boundaries of controls indicating the hit area require a minimum contrast ratio of 3 : 1. This is equal to that of the contrast requirement of large text in 1.4.3 Contrast minimum in WCAG 2.0.


People with low vision should be able to identify meaningful non-text controls and visual effects without relying on any color enhancing features or applications. The clear identification of selections, focus indications and hit areas even help those who have cognitive difficulties.

1.4.11 Non-text contrast required and exceptional elements

The following are some indicative elements and exceptions. On websites the list may be more.

  • Text embedded controls, graphics, text / placeholders in text boxes need 3 : 1 contrast ratio.
  • Developer defined focus indicators require 3 : 1 contrast ratio.
  • Actionable controls require 3 : 1 contrast ratio.
  • Visual effects to notify the selection need 3 : 1 contrast ratio.
  • A focus indicator required to have a contrast ratio of 3 : 1 with its adjacent background if the focus indicator is modified by the developer. If the  focus indicator is the default supplied by the browser, contrast is not required to be 3 : 1.
  • IF the state of a control is identified by means other than color change alone, the control and the visual selection identifier does not require 3 : 1 contrast ratio.
  • The visual boundary of any control that indicates the hit area is not a requirement of this success criteria 1.4.11 Non-text contrast, however if the visual boundary is the only way to identify the control when the user focus, then the visual boundary must have a 3 : 1 contrast ratio with the adjacent background color.
  • Inactive controls on the page such as a disabled button is not required to meet 3 : 1 contrast ratio.
  • Parts of graph, controls, text or icons are not required to meet the 3 : 1 contrast ratio if they have content available in another forms such as a table in addition to text on graph, if the graphics or icons are just for aesthetic purposes or that are part of logo / brand names.