2.1.4: Character Key Shortcuts

Success Criterion 2.1.4 Character Key Shortcuts (Level A): If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

  • Turn off

    A mechanism is available to turn the shortcut off;

  • Remap

    A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);

  • Active only on focus

    The keyboard shortcut for a user interface component is only active when that component has focus.

 

 

 

 

 

Description

 

Some applications may have character key shortcut keys to trigger actions and this character key shortcuts help keyboard users in using the application efficiently and effectively. Before we understand how the character key shortcuts are used by different users, it is important to know what is this character key shortcuts all about

Character key shortcuts are nothing, but actions get performed/triggered as soon as user presses characters on the keyboard, and this characters include letters(upper-case and lower-case), punctuations, numbers or symbols. Let me explain you this with an example. As you all know, there is popular web Gmail application to check our emails. Gmail has provided character key shortcuts for the users to perform certain actions quickly. When user presses character “Y” in the Gmail web, for the instance, email is going to be archived. Similarly, when user presses “M”, for the instance, mails are going to be muted.

 

Problems/challenges

 

although this character key shortcuts are very helpful for the keyboard users in accessing the things quickly, it creates problems for the speech input users and low dexterity users. Let us understand how this character key shortcuts are going to create problems for those users.

As you may be aware of, speech input users use speech recognition software such as dragon to access the computers/web. While dictating the text at the text field by speech user when character key shortcuts are present then it is going to pick the character key shortcuts instead of the text is being typed at the text field. This behavior creates problem to speech input users and as a result, speech input users cannot use the application properly. On other hand, there are some keyboard users(such as users with low dexterity, users with tremors, and so on.) who are prone to hit the keys accidently. When they do so, character key shortcuts get enabled unexpectedly. This behavior ends up with frustrating experience for such users. In a nutshell, character key shortcuts create challenges/problems for the speech input users and some keyboard users(such as users with low dexterity, users with tremors, and so on.)

 

 

Solution

WCAG 2.1 introduces character key shortcuts checkpoint to address the challenges with character key shortcuts that people with disabilities face. When author follows the guidance that is provided in this checkpoint then the challenges with character key shortcuts are going to be resolved. Let us look into what guidance this checkpoint is providing

 

  1. Turnoff: users should be able to turn off/disable the character key shortcuts, so that It helps both speech input users and low dexterity users to access the applications without any difficulties
  2. Remap: users should be able to remap the shortcuts with one or more modifier keys(such as alt, shift, control, and so on…), so that It helps both speech input users and low dexterity users to access the applications without any difficulties
  3. Active only on focus: users should be able to use the character key shortcuts only when that UI component(such as listbox, dropdown, and so on…) is in focus, so that it does not create a problem for any user

 

When author follows any one of above 3 points then challenges with the character key shortcuts that I mentioned in the problem section of this blog post are going to be addressed. In a nutshell, both speech input users and low dexterity users would not face any challenges when one of above 3 points is met.

 

 

 

Exceptions

This checkpoint is not applicable for the UI components such as listboxes and drop-downs. the reason is that, even though character key shortcuts are present for those UI components, those character key shortcuts work only when the UI components are in the focus. Therefore, this checkpoint does not affect such UI components.

 

Complimentary info on 2.1.4: character key shortcuts

When users have the provision to remap the character key shortcuts then it is going to help cognitive disability users too. Remapping the character key shortcuts with user’s familiar keyboard short cuts helps the users to use the same keyboard shortcut keys across various applications and thereby, it reduces the cognitive load.

 

 

References

 

 

 

2.5.1:Pointer Gestures

Success Criterion 2.5.1 Pointer Gestures (Level A): All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

 

 

 

Description

 

Problems/challenges

With the advent of smart or touch phones/devices, most of us started using the web on the mobiles. While accessing the web on mobile devices, it is quite common that users need to use certain gestures to complete the task. If those gestures are simpler then all the users including people with disabilities can use those gestures without much difficulties. However, there might be complex gestures as well to do certain tasks on the web. It may be true that people without disabilities would not have any problem in accessing those complex gestures, but A user may find it difficult or impossible to accomplish these if they have impaired fine motor control, or if they use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulation. The examples of such complex gestures are pinch to zoom, split tap(where we hold one finger and tap with other finger), 2 or 3 finger tap, 2 or 3 finger scroll, and so on.. the examples that I provided as part of complex gestures are called as multipoint gestures. Multipoint gestures are nothing, but it requires more than one touch point to activate the functionality. Since multipoint gesture require more than one touch point to activate the functionality, it is kind of problem for the people who have low dexterity/people who use  a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulation in accessing the same. In addition, remembering such multipoint gestures increases cognitive load and thereby it creates problem for the people with cognitive disabilities too.

Apart from multipoint gestures, sometimes, users need to follow specific/particular path to complete certain tasks, and these gestures are called as path-based gestures. The example for such path-based gesture is swiping. When user swipes from left to right and vice-versa on the content slider  then it displays next/previous slide correspondingly. Since path-based gestures require users to follow particular path, it is kind of problem again for the people who have low dexterity in accessing the same.

 

Solution

WCAG 2.1 introduced the new checkpoint called “2.5.1:pointer gestures” to address the problems with multipoint and path-based gestures for people who have low dexterity. This success Criterion states that functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture. To satisfy this success criterion, authors need to provide an alternative mechanism for the people with motor disabilities to access those path-based and multipoint gestures. The alternative is to provide single pointer. Single pointer is nothing, but pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures. Let me explain with few examples how the single pointer is an alternative for multipoint and path-based gestures.

  1. There is map on the web. To zoom the map, user may have to pinch with 2 finger(multipoint gesture). The + and – buttons can be added on the map as alternative for the users who cannot perform such gestures
  2. There is photo gallery on the web. Users may have to swipe(path-based gesture) to display next/previous photos. The right and left arrow icons can be added on the gallery as an alternative for the users who cannot perform such gestures

 

 

Basically, providing single pointer as an alternative for the multipoint and path-based gestures enables all the users including people with disabilities in accessing all the functionalities/features on the web.

 

 

 

Exceptions

  1. This checkpoint is not applicable If Those multipoint and path-based gestures are essential to the content. For an example, signature requires path-based gesture, and it is sometimes essential
  2. This checkpoint is applicable for only author supplied gestures but not user agent, operating system, assistive technology gestures

 

 

Complimentary info on 2.5.1: pointer gestures

The end points that follow particular path considers to be path-based gesture in this success criterion. However, the end points that do not follow particular path(random path) considers to be free-form gesture and this is not considered as path-based gesture. The example of free-form is drag and drop. Although free-form gestures do need single-pointer gestures as an alternative, this seems to be difficult for the author to implement. Therefore, free-form gestures are not covered as part of this success criterion

 

 

References

Understanding success criterion 2.5.1:Pointer Gestures

 

 

 

1.4.10:Reflow

Success Criterion 1.4.10 Reflow (Level AA): Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

 

 

Description

As you may be aware of, certain group of low vision users use browser zoom functionality to see the web content. However, this sometimes might be difficult to view the content by scrolling in both horizontal and vertical directions. To put it simpler, it takes lot of time and effort to read the web content by scrolling into both the directions. This is kind of problem.

WCAG 2.1 introduced the new checkpoint called “1.4.10: reflow” to address such problems for the low vision users. This success criterion requires Content to be presented without loss of information or functionality, and without requiring scrolling in two dimensions when the content is zoomed up to 400%. When authors follow this success criterion then entire web content reflows in one single column  without horizontal scrolling at 400% zoom. This enables low vision users to read the web content smoothly without horizontal scrolling.

Another important point to remember is that reflow should happen only at 400% zoom of screen resolution 1280px by 1024px but reflow need not to happen at 400% zoom of any screen resolution. This means that 400% zoom at screen resolution of 1280px(width) by 1024px(height) is nothing but 320px(width) by 256px(height). To put the things simpler, authors need to make sure that content should reflow either at 320px by 256px screen resolution or at 400
% zoom of 1280px by 1024px screen resolution. Basically, if your site is responsive then this checkpoint is almost going to be satisfied

 

Exceptions

This checkpoint is not applicable for the content that requires 2-dimensional scrolling. The reason is that such content will not deserve the meaning if it reflows in one direction. Examples of such content are data tables, videos, graphs, and so on.

 

 

Complimentary info on 1.4.10: reflow

The success criterion applies to both horizontally and vertically written languages. When 400% zoom is done on the horizontally written language content that scrolls vertically(ex: English)then it should not have horizontal scrolling. Similarly, when 400% zoom is done on the vertically written language content that scrolls horizontally then it should not have vertical scrolling. For the content that is horizontally written languages, the content should reflow vertically at 320px(width). For the content that is vertically written languages, the content should reflow horizontally at 256px(height).

It is often misunderstood that 1.4.4-resize text and 1.4.10-reflow are kind of similar, but both are different concepts. 1.4.4-resize text talks about all the content and functionality should be available at 200% zoom whereas 1.4.10-reflow talks about the all the content and functionality should be available at 400% without horizontal scrolling.

 

 

 

References

 

 

 

 

 

1.4.13-content on hover or focus

Success Criterion 1.4.13 Content on Hover or Focus (Level AA): Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

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.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

 

Description

While browsing the web, we quiet commonly see the tooltips. These tooltips typically appear when we hover or focus on the elements. Authors use these tooltips to provide more information about the trigger/target. Tooltip content could be submenus, non-modal, help text, so on… Users without disabilities neither have any concern accessing the tooltip content nor have disruptions with the tooltip content. However, users with disabilities might have disruptions with the tooltip content as well as problems/challenges in accessing tooltip content itself. tooltips, in general, impose lot of challenges to people with disabilities and let us look into them in-detail.

Problems/challenges with the tooltips

 

  1. You might know that certain group of low vision users use screen magnifier to view the web content. When these users magnify the web content, only less portion of the web content is visible in the view port. To access the complete web content, users of magnifier need to keep on pan the screen by using pointer and view the content in the restricted area. Imagine if entire portion of the restricted view port triggers additional content/tooltip then it is difficult or impossible for the users to pan the screen without retriggering additional content, and this is going to create a very big problem for such users.
  2. You might know that certain group of low vision users use keyboard. While accessing the web, low vision users who use keyboard may encounter the unexpected tooltips when they focus on the certain elements. This unexpected behavior may create a problem for the low vision users in accessing the obscured content.
  3. You might know that certain group of low vision users use large cursors. When those users use large cursor then large cursor may overlap the additional content/tooltip that is displayed on hovering the trigger/target. To view the additional content/tooltip content in such scenarios, users of low vision might have to move the pointer from trigger/target to the additional content/tooltip content. While doing so, tooltip content sometimes may get disappeared altogether, and this makes difficult or impossible for the low vision users to access the tooltip In addition, magnifier users might also need to move their mouse pointer to tooltip content to view/access the tooltip content properly. It is impossible or difficult for such users to view/access the tooltip content if the tooltip content gets disappeared as soon as pointer off from the trigger/target.
  4. You might know that certain group of cognitive disabilities take longer time to perceive the content. While they are perceiving the tooltip content, tooltips sometimes get disappeared automatically. When tooltips disappear automatically after a while then it is going to be difficult for such users to perceive the tooltip content.

 

Solution

WCAG 2.1 introduces content on hover or focus checkpoint to address the tooltip challenges that people with disabilities face. When author follows the guidance that is provided in this checkpoint then most of the tooltip challenges are going to be resolved. Let us look into what guidance this checkpoint is providing

  1. Dismissible: tooltip content should be dismissed when user presses escape key in the keyboard unless tooltip content does not obscure any content or tooltip content displays on the white/decorative background. This condition helps to resolve the problem 1 and 2 that are mentioned in the problem section of this blog post.
  2. Hoverable: user should be able to hover the tooltip content when pointer is moved from trigger/target to the tooltip content. Basically, the tooltip content should not be disappeared as soon as pointer of from the target. This condition helps to resolve the problem 3 that is mentioned in the problem section of this blog post.
  3. Persistent: tooltip content should remain on the screen unless user dismisses it or user navigates away from both trigger and tooltip content or the instance itself is invalid. Basically, tooltip content should not be disappeared after a while. This condition helps to resolve the problem 4 that is mentioned in the problem section of this blog post.

 

 

 

When author follows these 3 conditions then most of the tooltip challenges that I mentioned in the problem section of this blog post are going to be addressed. In a nutshell, people with low vision and people with cognitive disabilities would not face most of the tooltip challenges when the conditions of this checkpoint are met.

 

 

 

 

 

 

exceptions

This checkpoint is applicable only for the author supplied tooltips but not user agent based tooltips. To give an example, tooltips that are displayed with the HTML title attribute are an exception to this checkpoint.

 

 

References

 

 

 

 

Alert role

Description

When user performs an action or submits the form on a web page then it is possible that web pages/web form may sometimes send back certain feedback. This feedback could be success message, error message, confirmation message, warning message, and so on. as soon as these messages are displayed, visual users can perceive them immediately. However, the same is not possible for the screen reader users as screen reader users may be accessing the web page elsewhere. In this context, authors can use alert role(role=”alert”) to notify such messages to the screen reader users without moving the focus.

Typically, Alert role(role=”alert”) should be used for the important, and time sensitive, information. alert role(role=”alert”) is also a live region as like aria-live. To know more about what live region is, head on to my aria-live blog post. Since role=”alert” and aria-live are live regions, authors might think that those can be used interchangeably. However, authors should not use them interchangeably as both are used for the different purpose. Let me tell you the uniqueness of role=”alert”. When role=”alert” is used by an author then user agents are going to fire system alert event if the operating system allows. You might be wondering what system alert event is going to do if it gets fired. When operating system’s system alert is fired then alerts are going to be notified to the users even though user is in the different application. Therefore, role=”alert” should be used whenever it is appropriate.

 

Author notes

  • Authors should use role=”alert” for the alert messages that user need not to close
  • Authors should not use role=”alert” for the alert messages that user needs to close. Instead, authors should use role=”alertdialog” for such alert messages
  • Aria-live=”assertive” is the implicit value for the role=”alert” and hence, authors do not need to specify this explicitly
  • Aria-atomic=”true” is the implicit value for the role=”alert” and hence, authors do not need to specify this explicitly

 

 

Code snippet

<div role=”alert”>

Your session will expire in 60 seconds.

</div>

 

 

Complementary info on role=”alert”

As soon as web page is loaded, if authors think that certain information is important for the screen reader users to know, authors can use role=”alert” on such information on page load itself. Apart from that, when role=”alert” is used by an authors then some screen readers will notify the alert with wording “alert”

 

 

References

 

 

Aria-relevant(property)

Description

As we discussed in the past, assistive technologies like screen readers may not be able to notify the changes that are happening elsewhere on the page while user is going through the web content at his/her own pace unless live region is set. As part of live regions, we covered the aria-live and aria-atomic in the past. Let us understand about aria-relevant as part of this blog post. Live regions may contain multiple changes and all of them may or may not be required for the user to notify. To control these multiple changes, authors can use aria-relevant attribute. Let me give an example. Imagine there is chat log. As soon as there is new message in the chat log, user should be notified about this change because it is relevant in this contexts. Similarly, previous chat messages sometimes may be removed from the chat log to accommodate new chat messages in the log. However, this particular change need not to be notified to the user as it does not have any meaning.

To put it simpler, Aria-relevant is an optional property for aria-live and it basically talks about what type of changes to be notified to the users within the live region. Aria-relevant accepts list of token values such as additions, removals, text, additionstext, all.

 

Author notes

 

  • Aria-relevant can be used on any base markup and it is the global attribute
  • The default value of aria-relevant is additionstext for all elements. This means that authors can leave aria-relevant to it’s default value if assistive technologies to notify about the new node as well as modified node text/modified image alt text within the accessibility tree
  • Authors can set aria-relevant to additions if assistive technologies to notify about the new node
  • Authors can set aria-relevant to removals if assistive technologies to notify about the removal node
  • Authors can set aria-relevant to text if assistive technologies to notify about the modified node text/modified image alt text
  • Authors can set aria-relevant to all if assistive technologies to notify about all the changes such as new node, removed node, modified node text/modified image alt text

 

 

Sample code snippet

<ul aria-live=”polite”

aria-relevant=”additions”>

<li>Item 1</li>

<li>Item 2</li>

<li>item 3</li>

</ul>

 

 

Complimentary info on aria-relevant

The removals value of aria-relevant attribute should be used sparingly. In other words, Authors should

not use removals value in all the contexts rather authors should use removals value whenever it makes sense for the user to notify about the removed content. To give you an example, it is important/relevant  for the user to notify about who left the meeting in the virtual meeting/conference.

Another important point to make a note of removal value is that most of the screen readers except voice over do not have great support on removal value as of now.

 

References

 

 

 

 

 

 

 

What’s probably coming in the ARIA1.2?_part2

A Quick recap

This is the continuation of part1(what’s probably going to come in ARIA1.2-part1) blog post and we pretty much covered the new roles(such as blockquote, caption, code, deletion, insertion, and so on..)  that are probably going to come in the ARIA1.2 as part of the previous blog post. Let us look into the changes that are probably going to take place on the existing attributes and roles usage in this part2 blog post.

 

Changes that are probably going to take place on the existing roles and attributes usage

Combobox(role)

There are significant changes that are going to take place for combobox role(role=”combobox”)  in ARIA 1.2. ARIA 1.1 combobox role implementation pattern is going to be no longer valid once ARIA 1.2 becomes W3C recommendation as the support of ARIA 1.1 combobox role implementation pattern is not very great. ARIA 1.2 combobox implementation pattern talks more or less ARIA 1.0 combobox implementation with aria-controls instead of aria-owns.

 

Aria-disabled(state)

Aria-disabled attribute is not going to be global attribute any more and it is allowed only in the certain roles

 

Aria-invalid(state)

Aria-invalid attribute is not going to be global attribute anymore and it is allowed only in the certain roles. The value of aria-invalid is also going to be enumerated type and it means that aria-invalid accepts certain list of token values

 

Aria-errormessage(property)

Aria-errormesage attribute is not going to be global attribute anymore and it is allowed only in the certain roles.

 

Aria-haspopup(property)

Aria-haspopup attribute is not going to be global attribute anymore and it is allowed only in the certain roles.

 

Aria-expanded(state)

There are significant changes to aria-expanded attribute in terms of which role should allow and which role should not. Aria-expanded attribute is going to be allowed in the menuitem role, checkbox role and application role. In addition, aria-expanded attribute is not going to be allowed on many roles(such as alert, alert dialog, article, main, banner, contentinfo, and so on.)

 

Listbox(role)

Group role has been added as child of listbox role

 

The role(s) that is probably going to be deprecated

Directory

Directory role is going to be deprecated

 

Minor changes that are probably going to take place on the existing roles and attributes

  • The below roles are not going to have any default value(aria-checked)
    • Checkbox
    • Menuitemcheckbox
    • Menuitemradio
    • Switch
  •  

  • Checkbox role is going to support aria-required property
  • List role is not going to allow group role as it’s children
  • Row role in the context of treegrid is going to allow aria-positionset and aria-setsize attributes
  • Math role is going to allow children
  • Grid role is not going to allow aria-level as it’s supported attribute
  • Aria-valuemin and aria-valuemax are going to supported attributes for the below roles instead of required attributes
    • Separator
    • Slider
    • Scrollbar
  • Aria-orientation is going to be supported attribute for the scrollbar role instead of required attribute
  • The default value of aria-valuenow attribute for the spinbutton role is going to be 0
  • Spin button role is going to support aria-valuetext attribute
  • Default value of the aria-valuemin and aria-valuemax for spinbutton role is not going to be present
  • Certain roles(such as log, timer, and so on.) are not going to require accessible name

 

 

Editorial changes that are probably going to take place on the below roles and attributes

 

  • Alertdialog role
  • Alert role
  • Rowheader

 

Do you have a feedback on these proposed changes?

ARIA WG opened ARIA 1.2 for the public review around couple of months ago and feedback can be submitted in the W3C ARIA GitHub repository or can be emailed to public-aria@w3.org. ARIA 1.2 is probably going to be come candidate recommendation(CR) in a month or so. Later this year, hoping that it is going to be become W3C recommendation too

References

 

What’s probably coming in the ARIA 1.2?_part1

Overview

ARIA 1.2 main goal is to add certain new roles and update the existing attributes and roles usage based on the feedback that ARIA WG received. In addition, New terminologies like prohibited states and prohibited properties have been introduced. Prohibited states and prohibited properties are nothing but those attributes are not allowed for the certain roles. To give an example, paragraph role(which is new role in the ARIA 1.2) does not allow aria-label and aria-labelledby attributes and this means that authors must not use aria-label and aria-labelledby role on the paragraph role. ARIA 1.2 specification is currently in the draft stage and This means that ARIA 1.2 specification may subject to change based on the feedback. ARIA WG opened ARIA 1.2 for the public review around couple of months ago and feedback can be submitted in the W3C ARIA GitHub repository or can be emailed to public-aria@w3.org. ARIA 1.2 is probably going to be come candidate recommendation(CR) in a month or so. Later this year, hoping that it is going to be become W3C recommendation too. A big kudos to ARIA working group for working so hard for the evolution of ARIA and making the web better place for everyone!

 

New roles that are probably going to come in the ARIA 1.2

 

There are bunch of new roles that are probably going to come in the ARIA 1.2 and let us look into them one by one briefly. of Course, we will discuss them one by one in detail in the future once ARIA 1.2 becomes W3C recommendation

Blockquote

Blockquote role(role=”blockquote”) is related to HTML <blockquote> tag and authors can use this role on content that is quoted from the different source.

 

Caption

Caption role(role=”caption”) is related to HTML <caption> tag and HTML <figcaption> tag and authors can use this role to name/describe the table, grid, and figure. Caption role prohibits aria-label and aria-labelled by attributes.

 

Code

Code role(role=”code”) is related to HTML <code> tag and authors can use this role on the container that has the piece of the computer code. When assistive technologies like screen reader detects code role then screen readers are supposed to read all the punctuations. Code role prohibits aria-label and aria-labelled by attributes.

 

Deletion

Deletion role(role=”deletion”) is related to HTML <del> tag and authors can use this role either on the content that has been deleted or on the content that has been recommended for the deletion. Deletion role prohibits aria-label and aria-labelled by attributes.

 

Insertion

Insertion role(role=”insertion”) is related to HTML <ins> tag and authors can use this role either on the content that has been inserted into the document or on the content that has been recommended for the insertion. Insertion role prohibits aria-label and aria-labelled by attributes.

 

Meter

Meter role(role=”meter”) is related to HTML <meter> tag and authors can use this role on the element that has the scalar measurement within the known range or fractional value. Meter role and progressbar role cannot be used interchangeably and both are for the different purposes.

 

Paragraph

Paragraph role(role=”paragraph”) is related to HTML <p> tag and author can use this role on the content that is paragraph. Paragraph role prohibits aria-label and aria-labelled by attributes.

 

Subscript

Subscript role(role=”subscript”) is related to HTML <sub> tag and authors can use this role for the any meaningful text(not for the presentation purpose) that appears half a character below the normal line. Subscript role can be used for the chemical formulas like o2(oxygen). Subscript role prohibits aria-label and aria-labelled by attributes.

 

Superscript

Superscript(role=”superscript”) role is related to HTML <sup> tag and authors can use this role for the any meaningful text(not for the presentation purpose) that appears half a character above the normal line. Superscript role can be used for the footnotes. Superscript role prohibits aria-label and aria-labelled by attributes.

 

Time

Time role(role=”time”) is related to HTML <time> tag and authors can use this role on the content that represents the time/date.

 

Emphasis

Emphasis role(role=”emphasis”) is related to HTML <em> tag and authors can use this role on the any meaningful text(not for the presentation purpose) that is emphasized, but not on the text that is conveying importance. Emphasis role prohibits aria-label and aria-labelled by attributes.

 

Strong

Strong role(role=”strong”) is related to HTML <strong> tag and authors can use this role on the any meaningful text(not just for the presentation purpose)  that conveys importance/urgency/seriousness , but not on the text that is emphasized. Strong role prohibits aria-label and aria-labelled by attributes.

 

Generic

Generic role(role=”generic”) is related to HTML <div> tag and HTML <span> tag and this role is for the implementers of user agents but not for the authors. Implementers of user agents pass the generic role for those containers that do not have name and that do not have semantics to prevent the accessibility tree structure from the malware. Generic role prohibits aria-label and aria-labelled by attributes.

Just wait and take little bit break!

This is the series of the blog post and we pretty much covered the new roles that are probably going to come in ARIA 1.2 in this part1 blog post. To know what changes that are probably going to take place on the existing attributes and roles usage, head on to  part2(What’s probably coming in the ARIA 1.2?_part2)blog post

 

References

 

HTML address element accessibility

Description

HTML <address> element is introduced way back in the HTML 3. As per the HTML living standard, address element is to be used to provide the contact information for author/owner of document or article. For example, when added to an article, the address element provides contact information for the article author, and when added to a web page footer the address identifies contact information for the web page owner.

Contact information can be email address, physical location, website address, phone number. Address block cannot be used for arbitrary addresses and this is better explained in the author notes section of this blog post. As this is the standard, it is common that authors tend to use address element for such purposes. When author uses address element for such purposes then they may think it provides certain semantical information to assistive technology users. unfortunately, however, it is not the case and no screen readers provide semantical information to the users as of now. On other hand, voice over on iPhone/mac conveys as content information landmark semantics when address tag is used, and this is completely incorrect announcement/semantics. The bug is already filed on the same in the voice over WebKit Bugzilla.

Having said that, what announcement/semantics need to convey to the screen reader users when developer uses address tag. Answer is I don’t know. I am probably thinking that screen readers provide additional verbose like address along with the actual address whenever address block is used by developer. Since address block is not really adding any meaning to the assistive technology users and on top of that, it is creating problem to the voice over users, authors might think that it is not useful and may avoid using this all together. However, I am completely against to this. I would suggest that  authors need to add the address tag as per the standards to avoid the unknown complications and do certain work around(like add presentational role) for the voice over users to provide the best experience.

Author notes

  • <address> element should be used for the contact information relevant to the current site, page, document, section, or article. It should not be used to identify addresses in any other context.
  • Author should not include a postal address in the address block if it is NOT contact information. So, for example, if you have a real estate website, and you’re listing information about available houses, the address of a house listing should not be in the address block

Sample code snippet

  <address>

    You can contact author at <a href=”http://www.sumandamera.com/contact”>

    www.sumandamera.com</a>.<br>

    If you see any issues , please <a href=”mailto: sumandaa@gmail.com”>

    Email us</a>.<br>

    You may also want to visit us:<br>

    Suman Damera Pvt Ltd<br>

Nizampet<br>

        Hyderabad, , Telangana, 500090<br>

India

  </address>

Complementary info on <address> element

There is a reason why voice over is announcing <address> element as content info. The reason is that <address> element is mapped to ARIA content info landmark in the past in the  HTML AAM and therefore, apple treated this as content info landmark. To know more about this, please visit  HTML AAM GitHub. Later, HTML AAM for <address> element is updated with none of ARIA roles. To know more about this, please visit HTML AAM <address> element latest specification/edition.

References

HTML living standard: address element

aria-atomic(property)

Description

We discussed about live regions(aria-live) in the past and this post also related to the live region itself. Before we understand aria-atomic, let me just recap what is the live region all about. When parts or portion of the web page gets updated without reloading the entire page and that portion of page is set to aria-live then those areas are called as live regions. To simplify further, whatever the changes that are happening to the element/container that has aria-live with appropriate token values(assertive/polite) are going to be communicated/notified to the screen reader users. However, here is the tricky thing. The underlying fact with aria-live with assertive/polite token values is that aria-live just notifies changes alone, but not the entire content that is present in the live region. You might be thinking that What is the big deal if entire content in the live region is not communicated to the screen reader users. Let me explain this with simple example. I think most of us do shopping on the ecommerce website for one or other things these days. While doing shopping on the ecommerce site, it is common that, whatever the products that we like, we add to the cart. As soon as the product gets added to the cart, it is obvious for the visual users that product has been added to the cart. To communicate the same to the screen reader users, we set aria-live to assertive/polite for the dynamic container. Do you think aria-live alone with assertive/polite is going to solve the purpose? Answer is not to the full extent. The reason is that the changed content of the dynamic container is going to be communicated to the screen reader users when live region is set but entire  content in the dynamic container is not going to be communicated. This may create some problems for the users in understanding the live updates. Let us understand what problem we are going to face. When product gets added to the cart then screen readers notify the live updates like “1” or “2” or “3” or something like that. Do you think this type of notification is understandable? Answer is no. to make same notification understandable, screen reader should reread the entire content in the live region live “your basket contains 1” or “your basket contains 2” or “your basket contains 3” or something like that. To reread the entire content in the live region as and when user activates add to cart, aria-live alone is not going to help, and this is kind of problem.

To address this problem, aria introduces aria-atomic attribute. Aria-atomic indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute(We will discuss about aria-relevant attribute in the future blog posts). To put this  simpler, when aria-atomic is set to true for the same shopping cart live region and product gets added to the cart then screen readers reread the entire content like “your basket contains 1” or “your basket contains 2” or something like that. This kind of announcement is pretty much understandable instead of just announcing like “1” or “2” when user activates add to cart element. Aria-atomic attribute accepts 2 values and they are true and false.

Author notes

  • Aria-live can be used on any base markup and it is the global attribute
  • The default value of aria-atomic is false for all elements
  • Authors need to set the value of aria-atomic as true only  when the entire content in the live region along with the label of the live region(if exists) needs to be reread by assistive technologies.
  • If author sets explicitly aria-atomic as false, then assistive technologies stop searching up ancestor chain and present the changed node to the user
  • If author does not set aria-atomic attribute itself in the live region then assistive technologies, consider the default value of aria-atomic as false and present the changed node to the user.

Sample code snippet

<h2>Basket summary</h2>

<div aria-live=”assertive” aria-atomic=”true”>

    <p>Your basket contains <span id=”quantity”>0</span> items.</p>

</div>

References