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