ARIA Role Alert

The ARIA role is used to convey time sensitive and important information to the user without interrupting their current work process. The role="alert" must be provided to an element which holds the alert message. It is not required for author or developer to change or move user keyboard focus to the alert message when role alter is used. Screen reader picks the role alert and announces it for user even though the keyboard focus is  not on the alert message. It benefits user as their keyboard focus navigation flow is not disturbed.

Example : <p role="alert">Low battery. Please plugin to continue</p>

Whenever content having role alert is dynamically added in the page, screen reader stops announcing the present content and announces the dynamically added content with out disturbing the current keyboard focus. For example, assume screen reader is announcing a paragraph content present in middle of the page. So ideally focus is also present at paragraph content. Assume an alert message appears suddenly at top of the page. In this case screen reader stops reading the paragraph and announces the alert message without changing the keyboard focus to alert message. After completion of alert message, on hit of down arrow, screen reader continues reading the current paragraph which is in middle of the page. Hence with help of role alert, the important time sensitive information is conveyed to user without change in navigation flow or keyboard focus.

By default, when role="alert" is provided for an element, it implies the particular element has aria-live="assertive" and aria-atomic="true". Hence when role alert is provided then it is not required to use aria-live and aria-atomic properties.

Below are some scenarios when aria role="alert" can be used.

1. A text field where validation happens on the go when user start typing some value in the field. Ex: In email text field, if user enters special character other than @, an error message is shown immediately before user completes entering email. Here if role alert is provided for error message, screen reader announces it for user even though keyboard focus is in text field.
2. An online test where an alert is shown at top of the page when test time is about to complete. Ex: In online exam where user keyboard focus is at 45th question and an alert message is shown at top of the page stating "Only five minutes left". Here the error message is informed to user even though keyboard focus is at 45th question.
3. A storm alert message in a weather reporting website. Ex: User is browsing a weather report website. Suddenly an alert message is displayed on top of the screen "New Jersey weather alert: Thunderstorm and rain from 11am to 3pm." In this case, role="alert" must be provided for the alert message.

Key Points

1. The alert message should not disappear without user notice. Also, make sure that page doesn't contain too many alert messages as frequent interruptions makes it difficult for some users to continue working on the page.
2. The role alert is intended to provide time sensitive and important information for user without effecting user keyboard focus. If the alert message requires a change in keyboard focus or requires a user input, then it is recommended to use role 'alertdialog' instead of role 'alert'. Ex: A time-out notification where a dialog is shown with 'yes' and 'no' buttons in it. Here role alertdialog must be used instead of role alert.

How to make asp.net form elements accessible

In HTML, authors use <input> tag to create a text field or radio button or checkbox and <label> tag to provide a proper label for the input fields. The label and input fields are associated using ‘for’ and ‘id’ attributes. The value of ‘for’ attribute must be equal to value of ‘id’ attribute.

<label for=”firstname”>First Name</label><input type=”text” name=”fname” id=”firstname” />

Like HTML, ASP.NET has its own form controls for label and input elements. They are not same as those used in HTML. Let us see the asp.net equivalent tags for textbox, select drop down, check box and radio button.

Textbox:

The label and text box in asp.net is written as 

<asp:Label runat="server">First Name</asp:Label>

<asp:TextBox ID="firstname" runat="server" />

In asp.net, <asp:Label> will not support the conventional “for” attribute which is used to map the text fields. A property named “AssociatedControlID” is used for <asp:label> control. It is equivalent to “for” attribute in HTML. The value of “AssociatedControlID” must be equal to ID of text box.

<asp:Label AssociatedControlID=”firstname” runat="server">First Name</asp:Label>

<asp:TextBox ID="firstname" runat="server" />

The above asp.net code is converted into HTML when it is compiled and rendered in a browser. The “AssociatedControlID” attribute is converted to “for” attribute.

<label for=”firstname”>First Name</label>

<input type=”text” name=”firstname” id=”firstname” />

Note: If “AssociatedControlID” is not used, <asp:Label> is rendered as a <span> element instead of <label>.

<asp:Label runat="server">First Name</asp:Label> will be rendered as <span>First Name</span>

Checkbox & Radio button:

Unlike text field where explicit <asp:label> should be defined, it is not required to use <asp:label> explicitly for a checkbox and radio buttons in asp.net. Instead a property called “TEXT” has to be defined in checkbox tag and radio button.

<asp:CheckBox ID=”checkboxtest” text="Web Accessibility" runat="Server" />

It will be rendered as<input id=”checkboxtest” type=”checkbox” name=”checkboxtest” /><label for=”checkboxtest”>Web Accessibility</label>  <asp:RadioButton ID=”radiobuttontest” GroupName=”web” text="Web Accessibility" runat="Server" />
It will be rendered as<input id=”radiobuttontest” type=”radio” name=”web” value=”radiobuttontest” /><label for=”radiobuttontest”>Web Accessibility</label>

Fieldset:

To group the similar form fields, fieldset is used in HTML with a descriptive legend. Similarly in asp.net, “panel” is used to group the similar form elements.

<asp:Panel ID=”panelmain” runat=”server”>Form fields goes here</asp:Panel>

Browser generates <asp:Panel> tag as <fieldset> tag enclosed in <div>.

<div id=”panelmain”><fieldset>Form fields goes here</fieldset></div>

To get a legend tag, a property names “GroupingText” has to be used for <asp:Panel> tag

<asp:Panel ID=”panelmain” runat=”server” GroupingText=”Sample grouping”>Form fields goes here</asp:Panel>

Browser generates it as

<div id=”panelmain”>

<fieldset><legend>Sample Grouping</legend>

Form fields goes here</fieldset>

</div>

References:

ASP.NET accessibility

Make focus indicator accessible

In continuation to my previous blog post on focus indicator, here we learn on what makes browsers to suppress the default focus indicator and how to make it accessible.

When focus indicators are not visible?

The HTML elements are not rendered by browsers in the same way. Sometimes there would be mismatch in padding, margin for same elements when seen in different browsers. This behavior makes it difficult to achieve pixel perfect (maintain pixel to pixel accuracy as per visual design specifications) while developing a web page. Hence developers go for CSS reset style sheet which has a set of CSS rules that resets the styling of all HTML elements to a consistent baseline.

Sample code:

In the sample code, the css properties are set for few html elements in reset.css.

html, body, div, span, applet, object, iframe,h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, button, input {

            margin: 0;

padding: 0;

            border: 0;

            font-size: 100%;

            font: inherit;

            vertical-align: baseline;

            outline : 0;

}

As per above sample code, developers uses css property outline: none for following reasons.

•  A large focus indicator which sometimes occupies the entire row if developer provides an image inside an anchor tag.
• It is rarely misunderstood that the focus indicator occupies some space and breaks pixel perfection
• Developers assume there is not harm with presence of outline and does not think to remove it.

Impact on Accessibility:

But, due to the presence of outline: none, all browsers suppress the default focus indicator they generally show for all interactive elements making it inaccessible for certain users. Motor disability group users who rely on keyboard will not know where their current keyboard focus is and hence cannot activate the interactive elements precisely. Hence they may have to rely on someone to complete their task.

Remedy:

1.      Removing outline:

A straight forward remedy is to remove the “outline: none” property from reset css file. By removing it from reset.css, browsers will show the default focus indicator for all interactive elements and makes it accessible for all users.

2.      Define separate styles:

Instead of removing the outline: none property, define separate styles for anchor element. In the above code snippet, remove the anchor and define it separately without outline: none.

Sample code:

html, body, div, span, applet, object, iframe,h1, h2, h3, h4, h5, h6, p, blockquote {

margin: 0; padding: 0; border: 0; font-size: 100%; font: inherit; vertical-align: baseline; outline : 0;

}

            a{

margin: 0; padding: 0; border: 0; font-size: 100%; font: inherit; vertical-align: baseline;

}

3.      CSS Pseudo classes:

Pseudo class is used to define the special state of the element like hover (when user mouse over on an element), focus (when keyboard focus is on an element) or activates it.

Instead of removing outline: none from reset css, use pseudo class: focus. Define the outline explicitly for anchor elements when they receive keyboard focus using “: focus” pseudo class.

Sample code:

html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, a {

margin: 0; padding: 0; border: 0; font-size: 100%; font: inherit; vertical-align: baseline; outline: 0;

}

            a: focus { outline: 1px dotted black }

Here by default anchor element has outline: none property making browsers to suppress the default focus indicator. But as outline is explicitly define in :focus pseudo class, browsers will overwrite the outline:0 and shows dotted black focus indicator with width of 1px. Hence users will still know where the keyboard focus is when they navigate through TAB key. 

Focus Indicator

Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)


A focus indicator is a dotted or solid line present around the tab-able elements such as links, buttons, and form fields. While navigating the page through keyboard tab key, the focus indicator appears around elements when they receive keyboard focus to indicate where the current keyboard focus is. All major browsers like Firefox, Chrome, Internet Explorer and Safari shows a thin dotted or solid line around the elements when they receive the keyboard TAB focus. But the focus indicator look different in each of the browsers. For example, Internet explorer and Firefox shows a dotted line where as Chrome shows a blue solid line.

All elements which are interactive with mouse should be operable using keyboard as well. All those elements which are operable with keyboard should have a visible focus indicator when they receive keyboard focus.

Benefits of Focus Indicator:

                     A visible focus indicator not only helps users with certain disabilities but also helps normal users to know where the current keyboard focus is when navigating the page through keyboard alone.

Imagine you are in internet café where mouse is not responding. In such situations you rely on keyboard to navigate the page, fill forms and submit the application. If you have to submit a form but there is no visual keyboard focus indicator around elements, then you might not know whether the keyboard focus is on button or when to hit the enter key. It may cancel the application all together if you submit the form but focus is on another button.

Following are different groups who majorly get benefited with presence of focus indicator:

Motor – Users who cannot use mouse and completely rely upon keyboard to navigate the web page and access interactions present in it.

Visual – Users who have low vision use screen readers often and keyboard to navigate the web page.

Cognitive – Users with memory limitations may lose the track they are working on.

CSS Outline property

What if we don’t like the default dotted focus indicator and want to create something fancy? Can an author or developer create a customized focus indicators for interactive elements? Yes, a customized focus indicator can be shown using “outline” which is a CSS property that draws a line around the elements.

Optgroup Accessibility

Earlier developers used to customize the html tags like div, ul, and li in order to group the related elements in a drop-down list. Most of such customized widgets are not keyboard accessible as well not screen reader friendly making them completely inaccessible.

Thanks to HTML5 for introducing <optgroup> tag which can be used to group the elements easily for developers without much effort as well as pretty much accessible for keyboard and screen reader users.

Optgroup is used to group the options in a selection list. Instead of having long list of options in a selection list, grouping them together helps user to handle them easily. Optgroup should be coded inside a <select> tag.

Nested grouping is not possible with optgroup tag. It mainly supports two attributes “label” and “disabled”. If an optgroup has the attribute “disabled”, then the particular options will be greyed out by few browsers and users cannot select the options either with keyboard or mouse.

Attribute	Description
Label	To name the group of options inside the drop-down list.
disabled	Indicates whether the items present in group are selectable or not.

Sample Code

<label for="food">what is your favorite food? </label>
<select id="food" name="food">

<optgroup label="Juices">    

 <option value="1">Apple</option>

 <option value="2">Banana</option>

 <option value="3">Kiwi</option>

</optgroup>

<optgroup label="Fruits">
 <option value="4">Apple</option>
 <option value="5">Banana</option>
 <option value="6">Kiwi</option>
</optgroup>
<optgroup label="Salads" disabled>
 <option value="7">Broccoli</option>
 <option value="8">Cabbage</option>
 <option value="9">Sprouts</option>
</optgroup>      

</select>

Screen Reader Behavior:

Screen reader announces the label along with the option value for the user. If an option group is having disabled attribute then screen reader will not announce them at all.

Screen Reader + Browser	SR behavior
JAWS 17 + IE 11	SR announces the option value along with label name. Ex: Apple (Fruits), Banana(Fruits)
NVDA 2015 + FF 47	SR does not announce the label when options are not expanded. But when user hits space key, the options list expands and SR announces as Fruits grouping – Apple 1 of 3 – Level 2 for each of the options.
Voiceover iOS9 + Safari	Screen reader appends the word ‘heading’ for labels (Fruits, Juices…) Ex: Fruits Heading, Apple, Banana
Talkback V6.0 + FF	Screen reader appends the word ‘disabled’ for labels (Fruits, Juices…) Ex: Fruits disabled, Apple, Banana.

Examples & Reference:

1.      https://www.w3.org/TR/WCAG20-TECHS/H85.html

ARIA Pressed

Aria-pressed is one of the states and properties of ARIA which is generally used for toggle buttons to inform the state of the toggle button. It indicates the state of the toggle buttons whether the button is pressed or not. Aria-pressed should only be used for toggle buttons. It should not be used for form submit buttons or buttons which opens a modal window.

Aria-pressed has three states: True, False, Mixed. 

Attribute	Description
aria-pressed=”true”	The button is a toggle button which is pressed
aria-pressed=”false”	The button is a toggle button which is not pressed
aria-pressed=”mixed”	Mixed value for tri-state toggle button

For a toggle button which is not pressed, developers should provide aria-pressed=”false” by default. Once user clicks/activates the button with mouse or keyboard, then developer should change the value to TRUE (aria-pressed=”true”).

Note: aria-pressed should be used only for toggle buttons. It should not be used at all for normal buttons which do not have toggle functionality.

Sample Code

Toggle button not pressed : <input type=”submit” value=”Bold” aria-pressed=”false” />

Toggle button pressed : <input type=”submit” value=”Bold” aria-pressed=”true” />

Not a toggle button : <input type=”submit” value=”Bold” />

Screen Reader Behavior:

Screen Reader + Browser	Aria-pressed state	SR behavior
JAWS 17 + IE 11	True	Bold Toggle button pressed
JAWS 17 + IE 11	False	Bold Toggle button
NVDA 2015 + FF 47	True	Bold Toggle button pressed
NVDA 2015 + FF 47	False	Bold Toggle button
Voiceover iOS9 + Safari	True	Bold Toggle button pressed Double tap to toggle setting
Voiceover iOS9 + Safari	False	Bold Toggle button not pressed Double tap to toggle setting
Talkback V6.0 + Chrome	True	Bold Toggle button ticked double tap to toggle
Talkback V6.0 + Chrome	False	Bold toggle button not ticked double tap to toggle

Examples & Reference:

1.      http://www.oaa-accessibility.org/examplep/button1/

2.      https://www.w3.org/TR/wai-aria/states_and_properties#aria-pressed

Web Accessibility

Web Accessibility

Introduction:

There is a saying “world is small”. I never believed it until I started using internet. Now a days we can get anything from internet, reach out to any person, watch a movie, book a ticket and order food etc. with just few clicks. As of most recent survey around 3.5 billion people uses internet. We even cannot imagine our life without internet.

Have you ever wondered how people with disabilities use internet and access the content present in the websites? Have you ever thought if it is possible for people with visual impairment to access the websites? You will find the answer for yourself after reading my next series of blog posts.

What is Web Accessibility

Among the 3.5 billion people who uses internet, it is believed that around 60 million people have at least one type of disability.

Web accessibility means making the content present in the web available and accessible for people with disabilities. Each and every user must be able to understand, perceive and operate the content or information present in the websites. To be short, Web accessibility means that people with disabilities can use the web.

Currently most of the websites have accessibility barriers and makes it difficult for people with disabilities use the web.

Why Web Accessibility

Implementing web accessibility helps people with disabilities to access the content present in the web without the help of other persons. It provides equal opportunities and equal access to several aspects like Government, education, employment, healthcare and many more for people with disabilities.

Also there is LAW in several countries which states the schools, universities, airways, government entities websites must be accessible to all. The websites or companies which fails to obey the law ends up paying billions of fine to government.

Below are the few benefits

1. Equal access and equal opportunities for people with disabilities.
2. Increase in customer base as users with disability chooses the product which is more accessible
3. Improves SEO ranking as implementing accessibility makes the content of the website very clear and well structured.
4. Abide to law

Web accessibility not only benefits people with disabilities but also benefits people without disabilities. For example user working on computer which does not have a mouse or the user has temporary motor disability due to broken hand.

Disability categories for Web

All though 60 million people who uses internet have at least one type of disability, all types of disability users won’t face trouble in accessing the content present in internet. But few types of disability users as listed below find it difficult to access the content present in web.

The major types of disabilities for web are

• Visual Impairment
• Hearing Impairment
• Mobility disability
• Cognitive disability

Sources:

http://webaim.org/intro/

https://www.w3.org/WAI/intro/accessibility.php