My CSUN 2018 experience

I spoke in the many conferences in the past but for the first time, I spoke on 2 different topics in the single conference and it was really amazing experience! Let me start with my travel. It was really hectic travel with about 32 hours from my home to Hyatt hotel, San Diego. By the way, usually, CSUN conference takes place for about 3 full days on various topics at the Hyatt hotel, San Diego. After the 32 hours travel, we reached to grand Hyatt hotel, San Diego on 19th march evening.

On 21st march, I presented the 2 topics along with my partners. After my 2 presentations, I started attending some of the sessions that interested me. Just for your information, there would be around 450 sessions happen in the different rooms/tracks during these 3 full days(8 hours per day). Some of my friends who are visually impaired felt difficult to navigate between rooms/sessions from one session to other session. Somehow, I(as a visually impaired) did not feel much difficulty while navigating between the rooms once the session was over. The reason was that there were lots of volunteers who were helping me whenever I requested for help. I would agree with one thing is that there is only 20 minutes gap from one session to other session and one needs to reach to their desired session within this time period. This would be bit challenge but it can be manageable. Coming to actual point, one need to plan which session he or she wants to attend among around 450 sessions and trust me, this itself would take bit time to choose the topics that interests us. I have almost taken 4 hours to choose the suitable topics for me. I also have visited lot of stalls/exhibiters. For your information-there were around 150 stalls. Especially while visiting stalls, we would not get tired as we get lot of refreshments like chock lets and all.  I really had good fun while visiting the stalls! Let me talk more about my papers now. The topics that we presented are:

  1. React to A11Y
  2. ARIA 1.1: An in-depth view into the new and shiny

React to a11y

I presented this topic along with my colleague Rajesh Gorijavolu. the session went really well and there were more than 40 participants. It was really well received. In fact, I personally received the positive feedback from others about this topic in the Deque party. By the way, Deque gives the party during the CSUN time and one needs to register to attend this party. Coming to the actual point, I always wanted to present the topic which is trending one in the market. My interest in working on the trending technology driven me to present this topic.

If you are curious to know about the summary of our topic then here it is

Abstract: React to A11Y

React is a JavaScript web development framework with a different approach to rendering. Most of the people use React as VIEW in the MVC. It offers simpler programming model and better performance.

Accessibility is an important element in web and app design. Every individual using the web site or app has the right to access same information on the web and to have a positive and equal experience. Accessible design is about enabling access for every user, regardless of disability and technology.

Does React connect to the Accessibility? In this presentation, you will learn best practices and tips on How React JS helps to make a website or app accessible? There are key notable features “virtual DOM”, “HTML in JS”, “focus management” are made React JS different and make a website or app is more accessible.

After this presentation you and your organization will fully understand how React JS helps in building accessible widgets. We will also demonstrate about how accessible the applications built over React are accessible for persons with different disabilities.

ARIA 1.1: An in-depth view into the new and shiny

I presented this topic along with another colleague Denis Boudreau. We never imagined we would get overwhelming audiences for this session. Yes, the room was full before 4 minutes to the session itself. In fact, there was waiting list too. The session went dam good! There were amazing questions by audiences. I was very excited about this. I was happy to see there were participants who are from aria working group. Overall, this is sensational presentation throughout my career so far. I would thank Manoj Venkata who is our colleague for preparing ARIA 1.1 examples. As I am part of aria working group, it made me to present this topic.

If you are curious to know about the summary of our topic then here it is

Abstract: ARIA 1.1: An in-depth view into the new and shiny

WAI-ARIA 1.1 extends on version 1.0, and provides a number of additional features to continue bridging the gap for accessibility in HTML. Through the addition of new roles, state and properties, WAI-ARIA 1.1 expands the potential of HTML 5.1 even further, and also aims to meet needs identified for more complex widgets, such as tree grids and tables. This presentation will go over some of the most significant attributes added to WAI-ARIA 1.1, changes to existing attributes, deprecations, impacts on both the desktop and mobile experiences, and overall support of these attributes with different assistive technologies. You will leave this presentation with a clear understanding of all the great accessibility improvements WAI-ARIA 1.1 has to offer.

 

That is all for now and will be back with another topic!

 

aria-roledescription property

We have been doing lot of things for an element like adding or changing the name of the element by using aria-label, adding instructions by using aria-describedby, changing the states like pressed/not pressed, checked/not checked by using other aria techniques. Is it possible to customize the name of role or role of the element? I did not mean from the button to link and vice-versa. I meant different. Let us understand with the scenario what I meant.

For ex: button is the name of the role. is it possible to change from button role to attachment button as name of the role? It is not possible in aria 1.0

Aria 1.1 introduced aria-roledescription property to customize the name of the role. The method is that Put the string or custom text in the aria-roledescription attribute and it would become as a role of the element. Assistive technologies would announce the string as name of the role that is presented in the aria-roledescription but not actual role of the element. Let us understand this better with the same scenario

Button role is the actual role of the element. If I want to change from button role to attachment role then I simply add the string “attachment button” in the aria-roledescription. That is all, assistive technologies would announce it as “attachment button”.

We need to be careful while using this attribute as it suppress the native role of the element and announces the string that is presented in the aria-roledescription attribute as the name of the role.

Author notes

  • Authors should use this property in conjunction with wai aria role or implicit aria semantics.
  • Authors should limit the use of this attribute to clarifying non interactive elements such as group or region or to provide the description for a widget.
  • Authors should ensure that The value of aria-roledescription is not empty or does not contain only whitespace characters.

 

Notes for assistive technology vendors

  • Assistive technologies SHOULD use the value of aria-roledescription when presenting the role of an element, but SHOULD NOT change other functionality based on the role of an element that has a value for aria-roledescription. For example, an assistive technology that provides functions for navigating to the next region or button SHOULD allow those functions to navigate to regions and buttons that have an aria-roledescription.

 

aria-current state

When there are set of elements, one among them is active, we have been communicating this state today with one or other techniques to assistive technology users. Techniques that we have been following:

 

  1. Using off screen techniques
  2. Using title techniques
  3. Removing href attribute or providing role=”presentation” if they are actionable elements

These are the hacking techniques to convey the current state of the element to the assistive technology users.

aria 1.1 introduced aria-current attribute to convey the current state of the element programmatically. We don’t need to use hacking techniques any more. Aria-current is enumerated type and accepts list of token values. They are,

 

  1. Aria-current=page, represents the current page within the set of the pages. For ex: in the pagination, we can set this attribute to the page which is currently active
  2. aria-current=”step”, represents the current step within the process. For ex: in the ecommerse websites, we have checkout process. Typically, checkout process consists of few steps such as billing information, shipping information, payment method, conformation and so on.. we can set aria-current=”step= to the step that is currently active.
  3. Aria-current=”location”, represents the current location within the context or environment. For ex: in the flow chart, we can set this attribute to the location that is currently active.
  4. Aria-current=”date”, represents the current date within the collection of dates. For ex: in the calendar, we can set this attribute to the date that is currently active
  5. aria-current=”time”, represents the current time within the set of times.
  6. aria-current=”true”, represents the current item within the set
  7. Aria-current=”false”, does not represent the current item within the set.

Notes for assistive technology vendors

  • Any other values apart from the mentioned values should be treated as aria-current=”true” by assistive technologies.
  • If the attribute is not present or its value is an empty string or undefined, aria-current state MUST NOT be exposed by user agents or assistive technologies.

 

Author notes

  • Author should not use Aria-current and aria-selected interchangeably as they are not one and the same and they are different. In few cases, author might have to use both aria-current and aria-selected. For ex:, in the tree view, aria-current is to be used for the currently active page and aria-select to be used for the item that user is navigated to..
  • Authors SHOULD only mark one element in a set of elements as current with aria-current.

 

 

Term role

We have definition role in the aria 1.0 and term role supplements the definition role. Term is nothing but a word or phrase with the corresponding definition and it is related to HTML <dt> tag. Let us take simple example to understand about this roles. Web Accessibility is the term. Provides equal access on the web for all the users including people with disabilities is the definition.

When the term and definition roles are not defined then screen reader does not understand what is term and what is definition over there. Screen reader announces that as paragraph without any semantics and this is a problem.

When term role and definition roles are defined then screen readers are expected to announce like as: “term web accessibility. Web accessibility definition provides equal access on the web for all the users including people with the disabilities”

Author notes

  • Term role should not be used on the interactive elements like links

 

Code snippet

<div role=”term” id=’test’ aria-describedby=”dfn”>

w3c

</div>

<div role=”definition” id=”dfn”>

World Wide Web Consortium

</div>

 

References

 

 

Table role

We have grid role in the aria 1.0 and we supposed to use this role only for interactive tables. However, we have been using the grid role even for the static tables. The method is that We define grid role and aria-readonly=”true” for the container. When we do so, screen reader announces it as read-only grid. With this announcement, screen reader users understand that it is a static table. Although the actual purpose is solved by using this technique, it is not appropriate method from the standards point of view.

To avoid all the confusions, aria 1.1 introduced table role for static tables and it is equivalent to the html table tag.

Author notes

 

  • Author should use either row or row group as a children for the table role.

 

Code snippet

<div role=’table’ id=’test’ aria-rowcount=’3′ aria-colcount=’2′>

<div role=’row’>

<span role=’cell’>cheese</span>

</div>

</div>

 

References

aria1.1 specification-table

 

wai aria1.1 authoring practices-table

 

aria1.1-table working example

Switch role

We have checkbox role in aria 1.0. We have been using this checkbox role for many toggling functionalities irrespective of the visual appearance is.. If the checkbox role is applied for the widgets that looks like on or off then screen reader announce it as checkbox not checked/checkbox checked, , which is not correct interpretation, which Is not appropriate, which is not logical, which is not more meaningful, which Is not more semantical. The reason is that visual appearance is on or off and screen reader announces it as not checked or checked and they do not identical/same. therefore, screen reader user does not perceive the same information as sighted perceives.

ARIA 1.1 Switch role helps to bring the same level of experience to the screen reader users as like how a sighted person perceives. When switch role is applied then screen reader announces as “switch on/switch off”, which is more meaningful, more logical, more appropriate. Switch role is nothing different from checkbox role and only to be used when visual appearance of the element is like on or off. Switch role has on/off values but not check/uncheck. Switch role does not have mixed value.

Author notes

  • Author should use The aria-checked attribute to indicate the input is on (true) or off (false).

 

 

Feed role

Most of you would have heard that about infinite scrolling or auto scrolling widgets. the common examples could be that all social networking websites like Facebook, twitter, LinkedIn. Basically, what happens here is that Stories or articles within the feed keep on getting added or removed as user navigates in this social networking sites and this would never end and it is an infinite. let us understand how sighted user navigates this widget.
There is a scrolling feature available on this widget. user can scroll by using mouse and view more number of articles. For ex: there are 5 articles or stories, let us say 1 to 5, within the feed container on the page. When user scrolls, it displays next set of 5 articles or stories, let us say 6 to 10. When user scrolls again, it displays another set of 5 articles or stories, let us say 11 to 15.

However, when screen reader user navigates through this widget in the reading mode then he or she encounters only those first five articles or stories. When I say reading cursor or reading mode then navigation is through down arrow only. After navigating the 5th article, he or she navigates to the footer region or navigates to the whichever the content is present after this widget. User does not get the 6th article during arrow key navigation and this is a problem. In a nutshell, auto scrolling feature is not accessible in the reading mode or browse mode for the screen reader users.

In order to address this problem, aria 1.1 introduced the feed role. When feed role is applied then assistive technology and browser interact with each other and provides the best experience to the screen reader users while navigating the auto scrolling widget in reading mode. In other words, it enables the screen reader user to navigate through all the articles within the feed container in the reading mode or arrow key navigation.

Author notes

 

  • Authors should use article role as children in feed
  • Authors SHOULD make each article in a feed focusable
  • Authors should provide brief label to each article in feed
  • Authors should provide more description to the articles in feed by using aria-describedby
  • Authors should set aria-busy while adding or removing the articles at either end of the list
  • authors MAY specify aria-setsize on article elements if article supply is static
  • authors MAY set aria-setsize to -1 if total number of articles is extremely large, indefinite, or changes often

 

Code snippet

<section role=”feed” id=”test”>

<article>This is article 1</article>

<div role=”article”>This is article 2</div>

</section>

 

 

References