Month: July 2018

4.1.3: Status Messages-New SC in the WCAG 2.1

by

July 29, 2018

1:51 pm

6 Comments on 4.1.3: Status Messages-New SC in the WCAG 2.1

WCAG

, ,

Success Criterion 4.1.3 Status Messages (Level AA): In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Description

As you may aware of, people with visually challenged use the screen reader software to browse the website or access the information on the web. While browsing the website, it is natural thing for anyone to perform some actions like submitting the form, adding items to the cart,  and so on..) in order to get the information that he/she is looking for.  when an action is performed then updates or changes(popping the error messages, success messages after adding the item to the cart, and so on..)  may take place then and there without page refresh on the few websites. Those updates are obvious for the visual users but the same updates may not be obvious to the screen reader users. When screen reader users are not aware of these updates/changes then they do not get the same experience like how the sighted person experiences while browsing the information. As a result, screen reader users may not understand what is going on the page and might end up with the confusion/frustration

In order to address these type of situations, WCAG2.1 introduced this new checkpoint. The intent of this Success Criterion is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn’t unnecessarily interrupt their work. Having said that, do you think all the changes that takes place in the dynamic website deal this success criterion? Answer is no. The scope of this Success Criterion is specific to changes in content that involve status messages. You might be wondering what status message is about. Status message has specific definition in the WCAG. There are two main criteria that determine whether something meets the definition of a status message:

  1. the message “provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors;”
  2. the message is not delivered via a change in context.

 

The changes to the content need not to be always addition of new text to the screen and may be in the other formats too(like non-displayed text specific to assistive technology users and non-text content. As long as the changes to the content meet above conditions, it fits within this success criterion.

Benefits

  • new content is announced to the screen reader users When appropriate roles or properties are assigned to status messages, in such a way as to assist blind and low vision users.
  • Assigning proper roles or properties to status messages provides possible future uses and personalization opportunities to assistive technologies for users with cognitive disabilities. assistive technologies for users with cognitive disabilities may achieve an alternative means of indicating (or even delaying or supressing) status messages, as preferred by the user

Pass scenarios

The below are the few scenarios where this success criterion is met

  • after recipient email address is selected from the suggested list in the email application, recipient email address is added on the screen. The screen reader announces as suman damera added. It is important to understand that the text “added” may not be visible on the screen but screen reader announces as suman damera added. In order to give the context to the screen reader users, the extra piece of information is necessary in the form of non-displayed content
  • after recipient email address is removed from the list of selected recipients in the email application, recipient email address is removed from the screen. The screen reader announces as suman damera removed. It is important to understand that the text ‘removed” may not be visible on the screen but screen reader announces as suman damera removed. In order to give the context to the screen reader users, the extra piece of information is necessary in the form of non-displayed content
  • while entering the password at the password text area in the few signup forms, there is a visual indication how strong the password is. . screen reader announces weak/weaker/strong
  • after the incorrect form submission, there is a message on the screen like 5 errors are found. screen reader announces as “5 errors are found”
  • after the successful form submission, there is message on the screen like your form has been successfully submitted, will contact you soon. screen reader announces the same.
  • after adding the items to shopping cart by using add to cart button of the product in the eCommerce websites, cart count gets updated visually like 0 to 1, 1 to 2, and so on.. screen reader announces as “item has been added to the cart and currently cart has 2 items”

 

Not applicable/exceptional  scenarios

The following scenarios identify situations where no additional author action is necessary. All cases are excepted from this Success Criterion since they do not meet the definition of “status messages.”

  • When an error message is displayed in the dialog then authors need to place the focus on the dialog. By doing so, screen reader announces the error message. In addition, this is not a change of content and it is change of context. Thus, this scenario does not fit into current success criterion.
  • When there is an expand/collapse element(such as menu, select, accordion, tree, ) and screen reader announces the state of the element(expand/collapse) appropriately then user understands whether content is revealed or hidden with the help of state itself. Thus, this scenario does not fit into current success criterion
  • When there is tablist widget and screen reader announces the selected state of the tab item appropriately then user understands whether content is revealed or hidden with the help of state itself. Thus, this scenario does not fit into current success criterion

 

 

Techniques

Here are the few techniques that author can use to meet this success criterion

References

 

aria-modal(property)

by

July 22, 2018

5:43 am

5 Comments on aria-modal(property)

ARIA

, , ,

First of all, Let us understand What is a modal. Modal is something that interrupts your current work flow on your main page and usually, user navigation is limited within the modal element itself. In other words, users cannot access the background content when modal is displayed. Even though visually the background content is inert/grade out, it is high chance that screen reader users can access the background content, which is a problem.

To address this problem, what we have been doing is that we use aria-hidden=”true” attribute to hide the background content from the screen reader users. When modal is closed, we flip the aria-hidden value from true to false, so that screen reader users can access the content when they are returned to the actual web page. These are the techniques that we have been following to hide/unhide the background content from the screen reader users.

Aria 1.1 introduced the aria-modal attribute to hide the background content directly instead of using aria-hidden attribute. Authors should use aria-modal attribute in conjunction with dialog/alertdialog role. When aria-modal is set to true in the dialog/alertdialog container then the expectation is that:

  1. Assistive technologies do not expose the background content
  2. User navigation is limited to the modal elements itself
  3. Assistive technology should place the focus on the modal element when it is displayed unless the focus has explicitly been placed else where

all these things are being taken care automatically when aria-modal=”true” is used. Imagine’, how cool it is. Hence,  we don’t need to use aria-hidden attribute any more.

Author notes

  • Author should use aria-modal attribute in conjunction with dialog/alertdialog role.
  • When a modal element is displayed, authors MUST ensure the interface can be controlled using only descendants of the modal element. In other words, if a modal dialog has a close button, the button should be a descendant of the dialog.

Sample code snippet

if given

<body>

<h1 id=”Test2″>Modal Dialog Box Test</h1>

<div role=”dialog” aria-modal=”true” id=”test”>

<input type=”button” value=”ok”/>

</div>

</body>

then the element with role=”dialog” and id=”test” exposes aria-modal=”true”

 

 

References

 

 

Cell Role

by

July 15, 2018

5:43 am

Leave a comment on Cell Role

ARIA

, , ,

When It is not possible to construct the tabular content by using HTML <table> tag for any reason then they are called as custom tables. On the similar lines, when we cannot use the HTML <table> tag then it is obvious that descendants of the HTML table cannot be used. When I say descendants then what does it mean with respect to the HTML <table> tag. The descendants of HTML <table> tag could be <td>, <th> <tr>, <tbody>, <tfooter>, <thead> and so on.. in other words, authors cannot use all the mentioned descendants unless HTML <table> tag is being used to construct the tabular content. Each descendant conveys some or other semantical information to the assistive technology users. Let me talk more about <t> descendant. <td> tag conveys the semantical information to the assistive technology users that it is a cell. Unfortunately, custom tables are constructed with <div> and <span> tags. Divs and spans do not convey the any semantical information to the assistive technology users and this is a problem.

In order to address this problem, aria 1.1 introduced table and cell roles. To provide the semantics to the custom table, author must provide Table role to the entire container. Similarly, to provide the cell semantics in the custom table, author must provide cell role. Cell role is related to gridcell and It is equivalent of HTML <td>. All the context that I made about the tables is related to the static tables but not related to interactive tables. To be very clear and precise, cell role must be used only for static tables that are having table role.

 

Author notes

 

  • Authors MUST ensure elements with role cell are contained in, or owned by, an element with the role row.

 

Code snippet

<div id=”foo” role=”table” aria-colcount=”8″>

<div role=”row”>

<span id=”test” role=”cell” aria-colindex=”4″ >test cell</span>

</div>

</div>

References

 

 

 

aria-errormessage property

by

July 8, 2018

10:20 am

Leave a comment on aria-errormessage property

ARIA

, ,

We have aria-describedby attribute in the aria 1.0. what we as authors have been doing is that we associate instructions as well as inline error message of the form control by using aria-describedby attribute. Let us understand what does an inline error message mean.

imagine there is a form on the page. Form has first name, last name, and submit controls. When submit button is invoked without providing any input in the both fields then it displays inline error messages. For the first name form field, it displays the “please enter first name” as inline error message. For the last name form field, it displays the “please enter last name” as inline error message. We have been associating these type of inline error messages by using aria-describedby attribute so far.

Aria 1.1 introduced aria-errormessage attribute to associate these type of inline error messages with the form fields. It claims that it is more semantic method to associate the error messages by using aria-errormessage instead of using aria-describedby attributes. The aria-errormessage attribute references another element that contains custom error message text.

Author notes

  • Authors can use this attribute on all the elements of base markup
  • author should use aria-invalid attribute in conjunction with aria-errormessage.
  • aria-errormessage should not be applicable if the object is in the valid state and either has aria-invalid set to false or no aria-invalid attribute
  • Author should ensure that error message is visible on the screen when it is displayed.
  • Authors MAY use live regions for the error message element applying either an aria-live property or using one of the live region roles, for example, alert.

 

Sample code snippet

<!– Initial valid state –>

<label for=”startTime”> Please enter a start time for the meeting: </label>

<input id=”startTime” type=”text” aria-errormessage=”msgID” value=”” aria-invalid=”false”>

<span id=”msgID” aria-live=”off” style=”visibility:hidden”> Invalid time:  the time must be between 9:00 AM and 5:00 PM” </span>

 

<!– User has input an invalid value –>

<label for=”startTime”> Please enter a start time for the meeting: </label>

<input id=”startTime” type=”text” aria-errormessage=”msgID” aria-invalid=”true” value=”11:30 PM” >

<span id=”msgID” aria-live=”assertive” style=”visibility:visible”> Invalid time:  the time must be between 9:00 AM and 5:00 PM” </span>

References