1.3.4 Orientation

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. (Level AA)

Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where binary display orientation is not applicable.



Most of the handheld or tablet devices has the option to lock the orientation of the device. For instance, on an iPhone you can lock the orientation from the control Center (Control Center > lock rotation). Some users lock the orientation of their device for their comfort or some users, since the device is placed on a fixed place the orientation cannot be changed i.e. the devices fixed on the arm of a wheelchair.

1.3.4 orientation wants authors not to create any content or functionality that is restricted to one orientation. This will allow the users to view and operate the content of websites and applications in the orientation they are comfortable with or the default orientation of the device.

So, any application should respect the device specific orientation if the device orientation is locked, If the device orientation is not locked, the application or website should pick the default system level orientation. User agents pick the system level orientation either by the default device orientation or the orientation determined by the device sensors. In any of these conditions the content and functionality should remain unchanged.

Also keep in mind that the operating mechanisms can be different in different orientations. For example in landscape orientation the navigation menu may be a hide/ show mechanism while in portrait the same may be a ham burger menu.

Content or functionality changed by the size of the display of the device are not covered by this success criteria. In other words, 1.3.4 orientation does not talk about the changes in the content and functionality displayed in different screen resolutions.



Some situations restrict the benefit of viewing the content in both orientations. They are considered as exceptions of 1.3.4 orientation and are mentioned below.

  • To capture a check, the  process in a banking app can be performed only in landscape due to the larger width compared with the height of the check. In landscape mode the width is usually more than height.
  • A Piano app can only be accessed in landscape so that all the keys of the app can be effectively used.
  • Slides viewed on projector or television cannot be rotated because of their fixed position.

Related Links

Orientation API

HTML5 draggable attribute

The HTML5 draggable attribute specifies if the element can be picked for dragging. Links and images are draggable by default. Since this is a global attribute HTML5 draggable can be used on any element of the base markup.

Using HTML5 draggable attribute

As specified this is a global attribute and can be used in any element of the base markup.E.g. <a href=”abcd.html” draggable=”true”>Checking draggable</a>

Values of HTML5 draggable attribute

HTML5 draggable attribute can be either true or false. If it is set to true it means that the element can be dragged and dropped in a different position. The attribute is usually used in drag and drop operation, re-arranging a list etc.

Screen Reader support for HTML5 draggable attribute

By the time of this writing HTML5 draggable attribute cannot be recognized by popular screen readers JAWS and NVDA on all popular browsers Mozilla Firefox, Google Chrome and MS Internet Explorer and Edge. This proves true with the use of screen reader specific text in the

Examples of 4 design patterns of drag and drop.



Making emoticons accessible and screen reader friendly

Making Emoticons accessible is something often ignored while exchanging information on the web. Emoticons share expressions, feelings and different other messages in the modern digital content. Conveying these expressions to assistive technologies such as screen readers is something often developers forget or ignore. Let us understand how to make emoticons accessible and assistive technology friendly.

Including emoticons in your markup

Emoticons can be added to your markup in various ways. Explained below are few of them. It is not necessary that every technique provided below can make emoticons accessible or may be suitable for the screen reader / browser combination. Pick the suitable one for your need.

Direct insert of emoticons


This technique may not be ideal in all situations. To make it more screen reader friendly you can add ARIA roles and properties to it.


Direct insert of emoticons with ARIA substitute


By inserting ARIA role img and aria-label, screen reader users will identify the emoticon with accessible name. This method also recognizes the emoticons as images with the use of role img.

Unicode values for emoticons



Using Unicode values is the old and most preferred  method for emoticons. The complete list of unicode values can be found here. The emoticons marked-up using unicode values are accessible in general.

Hexadecimal values for emoticons




In case the emoticons marked-up using Unicode values or hexadecimal values are not identified by screen reading technologies, they can be substituted with the aria techniques specified above.

Emoticon keyboards

As we discussed in our blog article titled accessibility problems on social media applications, users highly depend on emoticon keyboards that are available in the market. ON IOS I use a emoticon keyboard that has different symbols defined in different categories. VoiceOver recognizes each of them with appropriate accessible name. Like any other character on the keyboard I can just add that to my text area in any application. Here is some information on using emoticon keyboard with IOS. Some apps such as facebook messenger provides the user to pick the emoticons directly from the app. under expression picker.


Emoticon add-ons for screen readers

I recently found this NVDA add-on called emoticons. This is quite interesting. Being a screen reader user you might not know how to type in all the emoticons you could imagine. This add-on solves that problem for you. Once you install the add-on, press NVDA + i to open the insert emoticons dialog. Choose the emoticon you want. The emoticons below are thus written in this article.




Related Links



Accessibility Inspector in Mozilla FireFox 61 and beyond

Accessibility Inspector is now built into Mozilla FireFox 61. This feature will give a wonderful opportunity for the accessibility testers and consultants to review the accessibility properties of any element and provide a detailed description for the audit report. In this article let us understand , how to enable it and use the feature. Screen reader users, don’t be panic, this feature is also accessible with the screen reader.


How is this Accessibility Inspector useful?

Before enabling the feature, let us understand how is this useful.

For a screen reader to understand a button as a button or link as a link on the browser the accessibility APIs of the browser help. The accessibility APIs expose the role and other information that is required for the screen readers. The information exposed by accessibility APIs include semantically supplied roles such as <a>, <label> as well as those supplied by WAI ARIA such as role=”link” and aria-label.

What is Accessibility Tree

The roles and other information made available by accessibility APIs is presented in a hierarchical structure called accessibility tree. This is similar to a DOM structure but it only has the accessibility related properties.


Making the accessibility inspector available directly on the browser or via dev tools make the life of developers and accessibility testers easy. Eg: Using this feature one can quickly check if an image on the page has an alternate text or not, can easily identify the button displayed is really a button or an image with click functionality etc.

Enabling accessibility inspector on FireFox browser.


  1. Make sure you are running Mozilla FireFox version 61 or above. Menu > Help > About Firefox or Alt + h, a.
  2. Now open your developer settings. Right Click or  Application key or Shift + F10 and select inspect element or Control + Shift + i.
  3. Now open the Dev tools settings. Go to the three dots menu and select Settings or Press F1 (Function key 1).
  4. Navigate through the settings and check the Accessibility checkbox to checked state.
  5. Now the accessibility tab will be added to the Dev tools panel.
    Accessibility Inspector panel from Dev tools

Accessing Accessibility Inspector

Once the accessibility inspector is enabled there are two ways to access the properties of any  element.

Method 1: Simple Method

In this method you can directly navigate to any element on the web page and check it’s properties.

  1. Navigate to the element for which you want to check the accessibility properties.
  2. Right Click, hit the application key or Shift + F10 and select Inspect Accessibility Properties.
  3. The accessibility Inspector panel opens. Use the tab or shift tab to find the Accessibility tree. The accessibility tree should have the earlier selected element focused.
  4. Use a tab to move to the properties of the element.
  5. Use the arrow keys to navigate between different properties such as Name, role, action, value, keyboard shortcut, state, attributes etc.

Method 2: Not So easy Method

In this method you can navigate from one node to another in the hierarchical accessibility tree, choose any element you prefer to and check it’s accessibility properties.

  1. Open the dev tools. Right click or application key or Shift + F10 and choose Inspect element or shortcut Control + Shift + i
  2. Navigate to Dev tools toolbar. Use shift tab or tab to navigate within the Dev tools window.
  3. Move focus to Accessibility in the tool bar. Use left and right arrow to move within the toolbar.
  4. Activate the accessibility option in the toolbar.
  5. Press tab to move into the accessibility inspector panel and to Accessibility tree.
  6. Navigate within the accessibility tree and observe the elements in the structure. Up and down arrow to move between the nodes and left and right arrows to expand or collapse the same.
  7. To check the accessibility properties of any element, bring focus to that element in the accessibility tree and press tab to move to it’s properties.
  8. Use the arrow keys to navigate between different properties such as Name, role, action, value, keyboard shortcut, state, attributes etc.

See the video

Happy Accessibility.

aria-roledescription (property)

Aria-roledescription property is new in ARIA 1.1 specification. This property allow content author to provide an additional description for the role already available. aria-roledescription property can be provided to the elements that have native markup role or for those elements where role is provided with ARIA specifications.

Some screen readers typically localize the name of the role to enhance the user experience. This localized name of the role help the screen reader user to understand the purpose of the section / region or in some cases it explains the interaction method of the widget.

This property allow the content authors to overwrite the semantics conveyed by the screen readers. This will perhaps give an opportunity to have a uniform reading experience with different screen readers. Content authors must have aria-roledescription property set to the elements that either have ARIA role or the role set by the markup. Further the value of aria-roledescription property must not be empty.


 Sample code

<input type=”button” value=”upload” aria-roledescription=”attach resume” />

Sample Output:

Aria-roledescription used in roles

Can be used in all elements of the base markup.

Values of Aria-roledescription

A string that can provide additional description of the container or the widget.

HTML5 Download Attribute

HTML5 download attribute is new in HTML5 specifications. This attribute allows content authors to allow users to download the file just by clicking the link. HTML5 download attribute is used in <A> and <area> elements.


Using HTML5 download attribute

Many websites allow the users to download an image, a PDF file or a MP3 file. Different browsers allow users to download the file differently or different users may be comfortable with different techniques such as right click and say “save as” the file. This HTML5 download attribute allows the users to directly download the file by clicking or pressing enter on the link instead of navigating to it.

Along with the “href” attribute use the “download” attribute s mentioned in the examples below. Content authors even can specify a different file name for the downloading file. If the file name is not specified along with the download attribute the file will be downloaded with the original file name. Also in the download attribute along with the file name the format is not required to be specified. The format of the original file will be appended to the downloading file automatically.


Values of HTML5 download attribute

The value of the download attribute is the download file. There are no restrictions on the value. If the extension is not specified, the browsers will take the extension from the original file. Similarly if the value of the download attribute is omitted the original file name will be taken by the browser.


Screen reader support for HTML5 download attribute

HTML5 download attribute does not provide any additional hint to a screen reader users as of this date. I have tested with NVDA 2018.2 and JAWS 2018 the latest popular and most update screen readers as of this writing. I wish to have an additional hint directly from the attribute that speaks out to the user to hint “the link will download a file instead of navigating to a different page”. Until the screen reader  provide an additional support to the download attribute, content authors must provide the additional hint when this attribute is used.

Example with PDF

The example below downloads a PDF file with WCAG Level A and Level AA checklist

<br /> <a href="/wp-content/uploads/2017/09/WCAG-20-checklist.pdf" download="Level-A-and-AA-standards">WCAG Checklist</a><br />
WCAG Checklist

Example with image

<br /> <a href="/wp-content/uploads/2017/07/Seeing-AI-menu.png" download="IOSappmenu">download here</a><br />

download here

NVDA 2018.2 is released, Download and What’s new

NVDA the free Windows screen reader by NVAccess released the next version for 2018 i.e NVDA 2018.2 . The release include few new features, bug fixes and developer enhancements.

What’s new in NVDA 2018.2

  • row and column span for table cells is now reported

Support for new languages Mongolian, Swiss German.

  • All of NVDA’s Preferences can now be found in one settings dialog under NVDA Menu -> Preferences -> Settings, rather than scattered throughout many dialogs.
  • NVDA no longer fails to read the page when going back to a previous page in Microsoft Edge.
  • Labels of checkboxes and radio buttons in Chrome and Firefox are no longer reported twice when tabbing or using quick navigation in Browse mode.
  • aria-current with a value of false will be announced as “false” instead of “true”.

Complete list of new features, bug fixes and changes can be found here.

Download or update to NVDA 2018.2

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

updating to NVDA 2018.2

  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.

Monthly Accessibility Webinar – Start the Digital Accessibility Tour – July 2018

This accessibility webinar is aimed to bring more tech enthusiasts into the space of digital accessibility. Digital accessibility should be included in everything we do. i.e the email we right, the design we create, the interaction we think or the screen / page we develop. Together let us start the journey of digital accessibility and make web a better place for everyone. Already in the space of accessibility? No problem, join us to brush-up the basics. Are you a accessibility enthusiast, feel free to join us.


Rakesh Paladugula
Linkedin profile

Key Takeaways

  • What is digital accessibility ?
  • What are the benefits of digital accessibility?
  • What are the global accessibility standards
  • What are your roles being a Designer / Developer/ QE Engineer / Content Writer/ Program Manager.

Accessibility Webinar Timing

July 10th, 2018

  • 7 : 00 PM IST
  • 9 : 30 AM ET
  • 6 : 30 AM PT

Please fill the signup form below to attend the webinar.

Web Content Accessibility Guidelines WCAG 2.1 is now W3C Recommendation

W3C has notified Web Content Accessibility Guidelines 2.1 (WCAG 2.1) as W3C recommendation on June 5, 2018. This means certain new success criteria are added to existing WCAG 2.0 check-list. Still the W3C’s WCAG 2.0 Level A and Level AA are the recommended set of success criteria. To bridge the gap in the modern web technologies such as mobiles and to increase the use of web more comfortably by people with low vision and cognitive difficulties certain new success criteria are added.

What’s new in WCAG 2.1

There are 17 new success criteria in WCAG 2.1. In this 5 are Level A, 7 Level AA and 5 Level AAA. A new guideline 2.5 Input Modalities has been added to the principle Operable. The guideline 2.3 Seizures is modified to meet the new requirements i.e. 2.3 Seizures and Physical Reactions. A new Success Criterion 2.3.3 Animation from Interactions is included in the guideline.

More information on WCAG 2.1 Level A and AA success criteria

Low vision requirements in WCAG 2.1

1.4.10 Reflow (Level AA)

The intent of this success criteria is to allow the low vision users to use increase browse zoom up to 400% without the loss of most content when scrolled in any one direction. More information on 1.4.10 reflow.

1.4.11 non-text contrast (Level AA)

In WCAG 2.0, certain user interface elements are not clearly defined with color contrast requirements. The states and boundaries of user interface components those defined by author,  parts of graphics that are required to understand the content must have a contrast ratio of 3 : 1. More about 1.4.11 Non-text contrast.

1.4.12 Text Spacing (Level AA)

The intent of this success criteria is to provide enough flexibility for users who want to increase spacing between paragraphs, lines, words or characters can still be able to read the page without the loss of content. Users may use author defined styles or browser bookmarklets or any other features to achieve the required spacing. In addition to low vision users, users who are dyslexic will also benefit with this success criteria. More about 1.4.12 Text Spacing.

1.4.13 Content on hover or focus (Level AA)

The intent of this requirement is to avoid unintended interference of content such as tooltips, modals, popups when user interface element receives keyboard focus or hovered by pointing device. The accessibility problems caused due to these kind of content can be either user is not at all aware of the displayed content or user is not intended for the interaction or the new content may interfere user’s current task. More information about 1.4.13 Content on focus or hover.

4.1.3 Status Messages (Level AA)

Status messages must be made available for blind and low vision users without interrupting their current task. Status messages must be programmatically defined such that the assistive technologies can identify them and present to the user in most convenient way. More about 4.1.3 Status messages.

Cognitive requirements in WCAG 2.1

1.3.5 Identify input purpose (Level AA)

The intent of this success criteria is to provide an easy and personalized solutions when a page have input elements. By providing a meaningful additional information user agents or assistive technologies can provide simplest ways to fill in the data. More information about 1.3.5 Identify input purpose.

Mobile requirements in WCAG 2.1

1.3.4 orientation (Level AA)

In the realm of mobile, many applications provide content different in different orientations. Some content or elements that are available in portrait are not available in landscape or vice versa. Content authors must be aware that some users lock the display orientation of their devices or the devices may be fixed on a specific place such as on the arm of power wheelchair. This success criteria requires content authors to provide the content and elements available in both orientations. The placement or the sequence can be changed but the content and functionality must be made available. More about 1.3.4 Orientation.

2.1.4: Character Key Shortcuts (Level A)

The shortcut keys should not be character dependent. Having characters with only a combination of upper or lower case letters or punctuations may not be useful for users who depend on voice input and keyboard only users. Keyboard users may accidently activate the keys. This success criteria does not prohibit the use of access keys. More information on 2.1.4 Character key shortcuts.

2.5.1 Pointer Gestures (Level A)

The intent of this success criteria is to provide simple gestures to interact with the content. Multi pointing gestures and path based gestures will not be easy for many users and hence may not be benefit with content dependent on these type of gestures. This success criteria does not restrict the gestures supplied by user agents or assistive technologies. More about 2.5.1 Pointer gestures.

2.5.2 Pointer Cancellation (Level A)

The intent of this success criteria is to avoid accidental pointer inputs. Users with disabilities may accidentally focus on an user interface element accidentally that may cause in unwanted results. More information  about  2.5.2 Pointer Cancellation.

2.5.3 Label in Name (Level A)

The intent of this success criteria is to enable users who depend on voice commands to interact with the user interface components. Often the voice commands used by the user will be the visible labels. If the text on the visible label does not match with the accessible label where the accessible label is assigned as voice command the interaction will not be performed. Providing the visible label and accessible name as the same for text and images of text that have visible label will benefit not only mobile users but also users with cognitive difficulties. More about 2.5.3 Label in name.

2.5.4 Motion Actuation (Level A)

Motion actuations such as shaking or tilting should not be the only way of doing a function on the web. Additionally user interface components also should be available on the application to perform the same action. Sometimes the device may be fixed to a table or a wheel chair and motions cannot be performed. A mechanism should also be in place to switch off the motion actuating functions. People who have trimmers may accidentally shake the device which can cause in performing unintended action. More about 2.5.4 Motion actuation.



aria-placeholder (property)

Aria-placeholder property is new in ARIA 1.1 specifications. This property is used to provide a short hint for text input fields when it does not have any text. In other words the string supplied through aria-placeholder should be available whenever the value property of the text field is empty. The hint provided through this property can be a short description, sample text  or a format of the text expected in the input field.

The purpose of aria-label property and aria-placeholder property are different. Content authors should not use this property in place of aria-label.

Aria-placeholder property acts similar to HTML5 placeholder attribute. Here is an article about the accessibility concerns of placeholder attribute.

Screen readers read aloud the hint provided via aria-placeholder property only when the text box does not have a value in it. If a value or text is available in the text box screen reader announces the value instead of placeholder text.

In example one below, screen reader reads the value of text field while in example two it reads the date format (MM/DD/YYYY format) along with the label Birth Date.



Example 1

Example 2

In example 1,

Aria-placeholder used in roles

Aria-placeholder property is used in textbox role and inherits into search role.

Values of aria-placeholder

Aria-placeholder property holds a string whose value is equal to the hint provided for filling data into the text box.