AODA and Internal Websites

On By AWGIn Web AccessibilityLeave a comment

One of the questions many people have is “Does AODA apply to internal websites/web application that requires employee logins?”

Last week I was on a webinar and I asked the question and I am glad to be able to share this with you:

AODA deadline for A/AA are for public facing websites. However, there could be complaints related to accessibility issues from employees for discrimination and this will go above the AODA guideline. These will go to the supreme court for human rights matters. You should decide as an organization what your plan of action is. Make sure you have a plan so employees will not be discriminated.

As a good general rule, if you already have plans for your public websites, it wouldn’t hurt to apply the same on all the internal websites. It’s good for the long term and should save resources down the road as well.

Walk in the Shoe of a Screen Reader User: Navigate New and Old site

On By AWGIn UncategorizedLeave a comment

A while ago, I was asking a screen reader to help out testing a new web application. An interesting topic came up about how much harder it is for a screen reader user to get used to a new site. This leads to the feedback of how every little bit of what we can do to make a website accessible improves their user experience.

Imagine your area has a new grocery store that opened up. During your first visit, you usually browse around to get a sense which aisle has certain products. Next time you go in, you spent less time looking for the location of the product. Same concept applies to navigating website even for a regular sighted user.

Now imagine again but with your eyes closed……. For screen reader users, they need to learn a new website using keyboard shortcuts for their first few visits to a new site. If we can make the website more accessible, it will make their life a lot easier.

Accessible Date Picker

On By AWGIn UncategorizedLeave a comment

I met with a screen reader user who had mentioned a great example of accessible date form control:

Greyhound Canada has a accessible date picker control which allows screen reader user to edit the date with up and down arrow keys and also navigate using the pop-up calendar.

Greyhound Canada’s accessible calendar picker

There is also an accessible Bootstrap date picker available: ab-datepicker This date picker can be customized and has great accessible features when I put it to test with NVDA screen reader. When user navigate to the pop-up calendar it announces with detailed description about the calendar picker. If you are looking to add a accessible date picker to your page, this one is worth checking out for.

JavaScript Jump Menu

On By AWGIn UncategorizedLeave a comment

JavaScript Jump Menu is a common accessibility error seen on dynamic web pages with drop down menu that has onchange / onclick event:

This is a sample accessibility validation result using WAVE showing jump menu error

Solution 1

The easiest solution I found is to use jQuery:

First, assign a class name to the drop down list:

<select class =”myselect” ……>

Second, use the jQuery change event to trigger your method of events:

$(“. myselect”).change(function () {

myEvent();

});

Solution 2

You can also use JavaScript in a similar matter for the same result. Cory LaViska has a detailed explanation of removing jump menus error using JavaScript.

Required Form Fields

On By AWGIn Web AccessibilityLeave a comment

WCAG 2.0 has several recommendation on how to indicate and clearly identify required fields on a form. Let’s take a look at some of the recommendations:

Required form fields example 1

Indicate by using asterisk at each form field

Technique:

  • The required property is indicated by an asterisk placed next to the label element
  • Aria tag on form controls: aria-required=”true”

Required form fields example 2

Indicate [required] at each form field

Technique:

  • The required property is indicated by the word “required” placed next to the label element

Required form fields example 3

Indicate required fields by color and star icon using CSS

Technique:

  • Required fields are indicated by a red border around the fields and a star icon rendered via CSS using content:before.
  • Label tag includes: data-required=”true”
  • Form controls includes: data-required=”true”

Required form fields example 4

Indicate (required) beside form label along with use of aria tag

Technique:

  • Aria tag on form controls: aria-required=”true” and aria-label=”Test”
  • The required property is indicated by the word “required” placed next to the label element

What is a better or preferred solution? I have met with a screen reader user and have the user walk through these examples using JAWS. Here are the feedback:

  1. It’s better to indicate “required” rather than “optional” as it’s easier for the brain to process.
  2. Using “aria-required” is the best way for screen reader users to know the field is a required field.
  3. If “aria-required” tag is used, there may not be the need to indicate “required” label.