Rich Internet Applications (RIA) and Web Accessibility

Author: Ramón Voces Merayo (Universitat Autònoma de Barcelona)

Citation:  Ramón Voces Merayo. "Rich Internet Applications (RIA) and Web Accessibility"  [on line]., 9, 2011. 


Abstract: first we introduce the creation and execution of accessible web applications, and then continue to analyze the accessibility problems of Rich Internet Applications and the solutions that WAI-ARIA offer.

Keywords: Web Accessibility, Rich Internet Applications, RIA, WAI, WAI-ARIA

Table of contents 

1. Introduction
2. Building a rich website
    2.1 Developing RIA with standards
3. Executing an accessible web application
4. RIA Accessibility problems
5. RIA solutions for accessibility
   5.1 Operability and WAI-ARIA
   5.2 Semantics of the interactive elements and WAI-ARIA
   5.3 Live-regions
6. Improving the user's experience with WAI-ARIA
   6.1 Structural semantics
   6.2 Forms
   6.3 Labels
7. When RIA are not HTML
8. Conclusions
9. References


1. Introduction

It is easy to realise that the webpages we use now are very unlike those that were first used in the early stages of the Internet.  Now many websites are capable of surprising us with their graphic design, information design and contents that offer, along with many other things that until recently were absolutely unthinkable.

Surely one of the most surprising advances has been the user's usage model: In the beginning, the interaction paradigm was characterised by the lack of interactive elements (mainly links and forms) and where the page was the smallest unit of information, for which any user request implied a complete reloading.

Now there are many technologies, proprietary and public, that allow webpages to use the desktop application paradigm. That is, to create web applications with two fundamental characteristics:

  1. A high user interactivity, through many interactive elements that before were only viable in desktop environments (like menus, trees, sliders, etc.) which are programmable under any user event (a click of the mouse, pressing a key, drag and drop, etc.) and with a completely personalised aspect.
  2. A high speed response to the user's interaction. The minimum information unit is that decided by the developer: a tag, a table or even the whole page.  This way you can attain an immediate response to the user's actions by downloading only the absolutely necessary data.



Example of an RIA interface

There is no doubt that these types of applications, usually called Rich Internet Applications (RIA), may substantially improve the user's experience on the web.  However, there are a minimum of two aspects that must be kept in mind:

  1. Usability. The interactive model in conventional pages is extremely simple, but also extremely clear.  In RIA, the developers may create, use and personalise new and sophisticated elements of interaction that allow very complex interfaces that, in some cases, more than help the user, provoke confusion and doubt during use (Nielsen 2007).
  2. Web Accessibility. In many cases, the advances in technology represent a risk for web accessibility.  Currently, for conventional pages, web accessibility has had a decade long history and we can now say there is no technical reason for justifying accessibility. A history that, unfortunately, is not enough to grant accessibility to all changes made by RIA.

While both aspects are of interest, this article will focus on the latter: RIA Web accessibility. 

2. Building a rich website

In order to understand the problems of accessibility presented by RIA, we must first analyse the technologies use and the way in which they are developed.

In general, a rich webpage may be created following two models:

  1. Via standardised technologies like (X)HTML, CSS or JavaScript.
  2. Via embedded technologies, making use of specific (X)HTML tags that allow for the execution of external applications in the user agent. The most common technologies that follow this model are the proprietary technologies Adobe Flash and Microsoft Silverlight.

Initially, this article will focus on the development via standards that, in the previous section, specify the specific problems for embedded technologies.

2.1 Developing RIA with standards

From a developmental point of view, implementing RIA via standards does not involve very complicated changes in terms of the development process.



Programming layers for a webpage


As we can appreciate in the previous figure, and in short, in any webpage (RIA or not) we can distinguish up to 3 layers of development (Voces et al., 2009):

  1. The structure and content layer. This is the layer that defines the different blocks that make up the webpage (header, content, footer, browser, etc.) and the content it represents. Normally, the technology used in this layer is (X) HTML.
  2. The presentation layer. The layer on which the visual appearance is designed along with the layout of structural blocks and its contents. Normally, the technology used in this layer is CSS.
  3. The behavior layer. This is the layer that programs how the page should react up against the user's actions. This layer directly interacts with the DOM (Document Object Model) of the user agent, to know all of the interactions (mouse movement, click, keyboard, etc.), access all of the contents that page presents, and change them if necessary. For example, it is common to verify that the data entered by the user in a form is correct before being sent to the server, and changing the colour of the erroneous fields.  Normally, the technology used in this layer is JavaScript.

For the developer, the behavioural layer opens a world of possibilities, since it permits, amongst other things, to create modules that simulate the conventional interactive elements in any desktop application (like menus, buttons, trees, etc.). Currently there are many free libraries full of interactive elements (like qooxdoo, jQuery or Dojo) capable of improving the user experience and reducing the application's development time.

It is also in the behavior layer where the information updates are encoded: via a combination of technologies called AJAX, you can perform asynchronological data requests to the server (that is, without reloading the page) and immediately presenting them. This way, the user experience results similar to that of a desktop application.




Data flow in an information request via XMLHttpRequest



3. Executing an accessible web application

According to the new WCAG 2.0 (W3C, 2008), an application is accessible when it fulfils the following requirements:

  1. To be perceivable in the sense that any person must be capable of detecting the presented content.
  2. To be operable, in the sense that any person is capable of interacting with the interactive elements on the page.
  3. To be understandable, in the sense that any person is capable of understanding the meaning of the content.
  4. Be robust, in the sense that the content may be compatible with a greater variety of assistive user agents and technology.

Of course all aforementioned points depend on the implementation of the application. However, if we widen the focus a little, it's easy to realise that for a web application to be accessible it must be run in an accessible environment.  Or in other words, it is useless to develop an accessible application if, for example, the user is not capable of running it because the operating system can't.



A web application's run environment


From a bird's eye view, and for a web application, an accessible environment basically depends on 4 fundamental elements:

  1. An accessible operating system that allows the user to run the user agent with our application.
  2. An accessibility layer, whose function is to be the meeting point between the applications run on the operating system and the assistive technologies that users with disabilities use (like screen readers).
  3. An accessible user agent, that allows you to run the web application, access the accessibility information and make it available through the accessibility layer.
  4. Assistive technologies that are capable of adequately providing user accessibility either by accessing the accessibility layer, the user agent's DOM or through other mediums.

All of these elements must be implemented in a completely cooperative manner, since a problem in any of them may directly provoke accessibility problems. It's obvious that this is not a simple task, especially when keeping in mind that each element is created by different developers that often have different interests (Henry, 2006).

4. RIA Accessibility problems

The most common accessibility problems associated to RIA involve the way in which the interactive elements are created and used and the dynamic update areas.

Basically, RIA presents 3 accessibility problems:

  1. Operability problems. In conventional HTML pages, all the interactive elements may be selected and activated via the keyboard or mouse. However, in RIA, it is common to find interfaces that are only interactive with the mouse. This way, people that interact via a keyboard or any other assistive technology complementary to the keyboard are not capable of looking at and interacting with these elements.
  2. Semantic problems of interactive elements. The purpose of interactive elements on a conventional page are clearly defined and for (X)HTML there are tags and attributes that allow us to add the necessary semantics for assistive technologies to offer enough information for disabled users to perceive and interact with them. However, the specific interactive elements of the RIA lack these tags and attributes. This way, for example, a slider could be simply presented with two images (the bar and the position marker), without indicating its function (slider), its current position (position 3 of 5, for example) or its properties (maximum and minimum value, for example).
  3. Live-regions. The capacity for RIA applications to update parts of the information presented asynchronously on the page is a large inconvenience for assistive technologies, since if not implemented properly, they might not notice that the information has changed, and thus, not inform the user.

5. RIA solutions for accessibility

Luckily, there are many developers working to resolve all of the aforementioned problems, which in some way are coordinated via the Protocols and Formats Working Group (PFWG) from the Web Accessibility Initiative (WAI). Their most representative work is a set of guidelines called the WAI-ARIA (Web Accessibility Initiative- Accessible Rich Internet Applications) (W3C, 2010) (W3C, 2011) that, despite not being officially recommended by the W3C (currently its status is Candidate Recommendation), they are being used by the top developers, and in leading products such as Mozilla Firefox, Microsoft Internet Explorer, JAWS or NVDA.

The aim of WAI-ARIA consists in providing solutions to this new RIA usage paradigm, whether it means redefining (X)HTML´s attributes functions or defining other new ones.

Below we will analyse which are the proposals specified in WAI-ARIA for the aforementioned problems.

5.1 Operability and WAI-ARIA

One key web accessibility point is that all interfaces must be operative from a keyboard. The fundamental reason for this requirement is so that many people with disabilities access a page linearly. For example, people with motor disabilities enter element by element via the next key (normally the TAB key). Therefore, it is easy to understand that an interface that depends exclusively on the mouse may not be considered accessible

To resolve the RIA´s operability problems, it requires:

  1. A mechanism that allows us to select all of the interface's interactive elements via the next key.
  2. Define the keys that allow one to operate it once selected.



jQuery Sliders

For example, an interface as shown in the figure above, must be capable of allowing the user to select each of the sliders, and once selected, be able to increase or decrease its value.

With regards to interactive elements, according to (X)HTML specifications, only a series of tags can be selected (<a>, <area>, <button>, <input>, <object>, <select> and <textarea>) and the selection order is established relative to an attribute with a numeric value called a tabindex, so that the first element is what has the lowest positive value.

In order to allow interactive elements to be selected, WAI-ARIA redefines the operation of the tabindex attribute so that it can be assigned to any tag that generates visual content, granting it the following interpretation:

  1. If tabindex has a value greater than 0, its value is the established order.
  2. If tabindex has a 0 value, it is selected after the tabindex elements greater than 0 and in the order in which it appears encoded in the (X)HTML page.
  3. If tabindex has a value lower than 0 it can only be selected by programming it.



Example of tab order program with TABINDEX

With regards to the keys used for interacting with the selected elements, WAI-ARIA provides a series of recommendations for each of the most common interactive elements that in general, coincide with the keys that normally are used in the desktop environment. This way, we hope to avoid having different developers use different keys for the same interactive elements. For example, for sliders they recommend using the arrow keys.

5.2 Semantics of the interactive elements and WAI-ARIA

It doesn't help much to select a specific interactive element of the RIA if it doesn't really provide information to the user about its function and its current status.

In order to resolve this problem WAI-ARIA is based on the roles concept.  A role is just a type of tag that allows the developer to specify the function of a specific interactive element (a slider, a text box, a menu, etc.)

WAI-ARIA has defined a series of roles (one for each interactive element) via a taxonomy modelled in RDF/OWL (Resource Description Framework/Web Ontology Language) and each of them has been associated the pertinent attributes which define the properties and status of the interactive element.

For example, a slider will have a slider role, with properties aria-valuemax (its maximum value) and aria-valuemin (its minimum value) and its status is defined by the aria-valuenow attribute (its current value).



Accessibility of the sliders with and without WAI-ARIA


In the previous figure we can appreciate the accessibility information of two sliders (obtained via the Inspect32 application) and the HTML markups used. On the right slider, the WAI-ARIA is added and as we can see, assistive technologies would not have any problems recognising the roles, the current value and the current status.  However, for the role on the left, we have eliminated the WAI-ARIA markup, and it is no longer possible to recognise the role or the current value.

Finally, it is also interesting to note that WAI-ARIA provides two attributes that may further increase the semantics of the interactive elements.  The first, aria-owns, is designed to define parent/child relationship in complex interactive elements (like a tree or menu). The second, aria-controls, are designed to indicate in complex interfaces that the action on an interactive element changes (or controls) one or more elements of the same interface.

5.3 Live-regions

One of the fundamental characteristics of RIA applications is that they are capable of synchronically and dynamically changing the content of some of the regions of a webpage.  



Example of a live-region


Obviously the assistive technologies, especially screen readers, must be capable of properly managing these contents. For this to be possible, it is necessary that the developer includes the following information:

  1. That the part of the webpage be live regions, and if possible, specify the type of region (an alert, news broadcasts...)
  2. Get to know the priority in which the user must be informed of updates.  There are times in which it is necessary to inform the user urgently (for example, an error window), others when you can wait for the user to finish the task being executed, and others that don't even require reporting.
  3. Specify the information unit to offer the user.  That is, if is necessary to again inform the user of all of the content in the live region, or just of the changes.



Example of the markup of a timer in a live region

In the previous example, the WAI-ARIA markups inform the assistive technologies that the changes produced must be presented as soon as possible (aria-live="assertive") and that it must retransmit all the data in the live region (aria-atomic="true").

6. Improving the user's experience with WAI-ARIA

Without a doubt, all webpages must be accessible. But this is not enough:  besides accessible, they must also be usable.  Unfortunately, there are pages that from a technical point of view, may be considered as accessible but, end up too complicated for the user to be able to access the information presented.

Despite WAI-ARIA´s objective being to improve RIA´s accessibility, it also defines a series of mechanisms that may substantially improve end usability of webpages, what could be considered as another element of Progressive Enhancement. Specifically, structural semantic elements, forms and tags. 

6.1 Structural semantics

One of the most common problems of usability faced by the people with disabilities when linearly accessing the web is the difficulty arriving at the main content. As we know, one of the most sought-after design objectives for websites is coherency. This implies maintaining, in the same position, size and content, some of the blocks of its structure, like, for example, the header or global navigation system. Unfortunately, this principle of coherency requires the disabled to go through other common structures before arriving at the main content, page after page.

Until WAI-ARIA, some developers used various techniques like, for example, placing a link to the main content at the beginning of the page (Voces, 2010). In any case, when facing the complexity offered by many current interfaces, these are techniques that could be considered rudimentary.  

Surely the most important concept that WAI-ARIA introduces from a structural semantics perspective is a specific role called landmark. WAI-ARIA defines it as "a type of region to which a user can quickly access" and defines the following types: application, banner, complementary, contentinfo, form, main, navigation and search.

This way, a page marked-up with landmarks allow one to add all of the necessary semantic information so that the user agents and assistive technologies allow the user to navigate through landmarks.




Example of landmarks in the Firefox accessibility bar

On the other hand, landmarks are not the only structural semantic elements: there are also other roles as varied as toolbars, headings or articles.

6.2 Forms

Accessibility of forms has always been a key topic, since it represents the only mechanism that a user has to transfer information to the server, and thus, carry out operations as varied as registering for a service, making a purchase or sending a suggestion.

One of the most common and often most inaccessible aspects occur when notifying the user what are required or erroneous fields. In many occasions, the developers opt to resolve both problems by changing the presentation of fields (for example, changing colour).  Obviously these practices are not accessible.



Inaccessible use of colour for required fields in forms

In order to resolve these problems, WAI-ARIA introduces the aria-required and aria-invalid attributes to markup required and erroneous fields. This way the assistive technologies may properly inform the user.

6.3 Labels

Sometimes an interactive element's objective must be clearly stated.  For example, when creating a form, it is a good practice to associate a label to each of the fields, clearly stating what information must be entered. 



Combined box with label


As we can see in the previous figure, in (X)HTML this is resolved with the label tag. The problem with these labels is that they are only available for form elements.

That is why WAI-ARIA has created an alternative attribute called aria-labelledby, which can be applied to any tag. As we can see in the following form, the use is very similar to a label.



Use of aria-labelledby


7. When RIA are not HTML

A good part of RIA were developed with technologies other than (X)HTML. All of them, probably Microsoft Silverlight and, above all, Adobe Flash are the most popular and used.

Of course the focuses used are different (Microsoft, n.d.) (Adobe, 2010): while Microsoft Silverlight is exclusively based on the new accessibility layer developed by Microsoft called UI Automation, Adobe Flash is compatible with Microsoft´s MSAA layer (the precursor to UI Automation), Linux Foundation ´s IAccessible2 and the OSX´s AX accessibility layer. In any case, it is necessary to recognise that both companies have made a strong effort in developing accessibility in their products, and from a technical point of view, they may be considered potentially accessible. 

Unfortunately, in practice, a good part of the applications created with this technology are not accessible, in general, due to a deficient implementation.

Without a doubt, it is quite difficult to justify, above all, when there is enough documentation in both technologies, and furthermore, it does not suppose a major technical effort.

8. Conclusions

This article has started by analysing the way in which RIA are developed and the environment in which they are run, and then we analysed its accessibility problems and their solutions.

As we have seen, when referring to RIA, the main accessibility problems may be resolved with WAI-ARIA, and it also supported by the majority of operating systems, browsers and assistive technology companies.

But that there is still no official W3C recommendation, and therefore it may still be susceptible to changes.  It is also true that the pace in which the technology evolves (which often understands web accessibility as an improvement and not a requirement) and the business pressures for using the latest technology, does not make it easy for developers. 

However, nothing of that previously mentioned is an excuse for not creating accessible applications.  This is basically for 3 reasons:

  1. Inaccessible applications result in social exclusion, violating the rights of many citizens due to their disability.
  2. As a function of the website's characteristics, it is a legal obligation and may be sanctioned (Carreras, 2011).
  3. It is not necessary to create RIA applications to obtain a good web application. Excellent web applications may be developed through the use of standardised, tested, and accessible technologies and guidelines, without the need to use advanced interactive elements or live regions.

As a result, each organisation is free to choose whether to develop a conventional or RIA application.  But whatever the choice, the result should always be accessible. Because it is possible, and necessary. 

9. References

ADOBE. (2010). Flash Player and Flex support for IAccessible2 and WAI-ARIA. [En línea] [Consulta: 25/02/2011].

Carreras, Olga. (2011). Referencia sobre legislación española relacionada con la accesibilidad web. [En línea] [Consulta: 25/11/2011].

Henry, S. L. (2006). Understanding Web Accessibility. [En línea] [Consulta: 25/02/2011].

MICROSOFT. (n.d.). Silverlight Accessibility Overview. [En línea] [Consulta: 25/02/2011].

Nielsen, J. (2007). Web 2.0 Can Be Dangerous... [En línea] [Consulta: 25/02/2011].

Voces, Ramon; Codina, Lluís; Recorder Sellarés, Mª José. (2009). Comunicación audiovisual sin barreras: televisión pública, world wide web y accesibilidad. 1 ed. Santa Eulàlia de Ronçana: Anguiroda

Voces-Merayo, Ramón. (2010)."Diseño de arquitecturas de información lineales para mejorar la accesibilidad web". El profesional de la información, v. 19, n. 4, pp. 374-381.

W3C. (2008). Web Content Accessibility Guidelines 2.0. [En línea] [Consulta: 25/02/2011].

W3C. (2010). WAI-ARIA 1.0 Authoring Practices. [En línea] [Consulta: 25/02/2011].

W3C. (2011). Accessible Rich Internet Applications (WAI-ARIA) 1.0. [En línea] [Consulta: 25/02/2011].


Licencia Creative Commons

Last updated 05-06-2012
© Universitat Pompeu Fabra, Barcelona