{"id":5615,"date":"2020-10-05T13:40:00","date_gmt":"2020-10-05T13:40:00","guid":{"rendered":"https:\/\/azoora.com\/blog\/?p=5615"},"modified":"2020-10-04T13:43:31","modified_gmt":"2020-10-04T13:43:31","slug":"aria-web-standards-html-apps-accessibility","status":"publish","type":"post","link":"https:\/\/azoora.com\/blog\/information\/aria-web-standards-html-apps-accessibility\/","title":{"rendered":"ARIA Web Standards & HTML Apps Accessibility"},"content":{"rendered":"\n

A truly open and inclusive web needs technologies that allow disabled users relying on assistive technologies to enjoy dynamic web content and modern web apps. W3C\u2019s accessibility web standards aim to populate the web with Accessible Rich Internet Applications (ARIA)<\/a> that users with disabilities can efficiently use.<\/p>\n\n\n\n

ARIA is one of the numerous\u00a0accessibility standards and guidelines<\/a>\u00a0published by the Web Accessibility Initiative (WAI). It provides an additional markup that can be easily inserted into HTML documents. WAI-ARIA is a cross-platform an cross-device solution that\u00a0targets the Open Web Platform<\/a>, so don\u2019t only think about websites, but also about games, digital entertainment, healthcare, mobile, and other kinds of apps.<\/p>\n\n\n\n

In this post we will take a look at how you can add accessibility to your HTML documents with the help of WAI-ARIA standards.<\/p>\n\n\n\n

The ARIA Framework<\/h4>\n\n\n\n

The syntax of HTML doesn\u2019t always allow developers to describe elements properly, to identify their roles, and specify the relationships between them.<\/p>\n\n\n\n

While that\u2019s rarely a problem for visitors who are in full possession of their senses, it can impede assistive technology users from understanding what\u2019s happening on the screen and exploring their options.<\/p>\n\n\n\n

This is the point where ARIA comes to our help, as it makes possible to define the purpose of different elements with the help of landmark roles<\/strong>, and describe their nature with aria-prefixed attributes<\/strong>.<\/p>\n\n\n\n

Aria-prefixed attributes have two types: properties<\/strong> that describe features that are less likely to change throughout the page life-cycle, and states<\/strong> that provide information about things that may frequently change due to user interaction.<\/p>\n\n\n\n

Landmark Roles<\/h4>\n\n\n\n

Landmark roles<\/strong> are the most well-known forms of ARIA\u2019s Roles Model (others are the Abstract Roles, the Widget Roles, and the Document Structure Roles). Landmark roles enable developers to identify large perceivable regions<\/strong> on the web page that assistive technology users may want to quickly access.<\/p>\n\n\n\n

There are 8 types of ARIA landmark roles, and they need to be added as attributes to the related HTML tags.<\/p>\n\n\n\n

role=\u201dbanner\u201d<\/h5>\n\n\n\n

The banner role<\/a> is intended to be used mainly for content that is related to the entire site, not just to individual pages. It\u2019s usually added as an attribute to the main header of the site for the logo and other important site-wide information.<\/p>\n\n\n\n

It\u2019s important that you can use the banner role only once within any HTML documents or apps.<\/p>\n\n\n\n

role=\u201dmain\u201d<\/h5>\n\n\n\n

The main<\/a> landmark role is related to the main content of the document. It can\u2019t be used more than once on any HTML page. It usually follows the <div role=\"main\"><\/code> syntax, or in HTML5 the more semantic <main role=\"main\"><\/code><\/a>. The latter was added to the W3C specs with the purpose of mapping the main<\/strong> ARIA landmark role to a semantic HTML element.<\/p>\n\n\n\n

role=\u201dnavigation\u201d<\/h5>\n\n\n\n

The navigation<\/a> role is meant to be used for indicating an area that contains navigational elements such as links and lists on a site.<\/p>\n\n\n\n

role=\u201dcomplementary\u201d<\/h5>\n\n\n\n

The complementary<\/a> landmark role describes additional content that is related to the main content of the site. It needs to be placed to the similar level in the DOM hierarchy as role=\"main\"<\/code>. Related posts, popular articles, latest comments are typical examples of autonomous complementary content.<\/p>\n\n\n\n

role=\u201dcontentinfo\u201d<\/h5>\n\n\n\n

The contentinfo<\/a> role informs user agents about the presence of a region where different kinds of metadata, such as copyright info, legal and privacy statements can be found. It\u2019s typically used for the footer of a site.<\/p>\n\n\n\n

role=\u201dform\u201d<\/h5>\n\n\n\n

The form<\/a> landmark role indicates a form waiting for user input. For search forms you should use role=\"search\"<\/code> instead.<\/p>\n\n\n\n

role=\u201dsearch\u201d<\/h5>\n\n\n\n

The search<\/a> role is pretty self-explanatory, it\u2019s intended to help assistive technologies identify the search functionality of a website.<\/p>\n\n\n\n

role=\u201dapplication\u201d<\/h5>\n\n\n\n

You can use the\u00a0application<\/a>\u00a0landmark role for a region that you want to declare as a web app, rather than a web document. It\u2019s not recommended to include it in traditional websites, as it hints to assistive technologies to switch from normal browsing mode to application browsing mode. You should only use this landmark role with great care.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

States and Properties<\/h4>\n\n\n\n

While roles enable you to define the meaning of HTML tags, states<\/a> and properties<\/a> provide the user with extra information on how to interact with them. Both states and properties are marked with aria-prefixed attributes<\/strong> with the syntax aria-*<\/strong>.<\/p>\n\n\n\n

The most well-known ARIA attributes are probably the aria-required<\/a> property and the aria-checked state. Aria-required is a property<\/strong> because it\u2019s a permanent feature of an input element (i.e. the user must fill it in), while aria-checked is a state<\/strong> because a checkbox may frequently change its value due to user interaction.<\/p>\n\n\n\n

The Syntax of Aria-prefixed Attributes<\/h4>\n\n\n\n

States and properties sometimes take token values (a limited set of predefined values), for instance the aria-live<\/a> property can have 3 different values: off<\/em>, polite<\/em>, assertive<\/em>. The syntax in this example looks like this: <div id=\"some-id\" class=\"some-class\" aria-live=\"assertive\"><div><\/code>.<\/p>\n\n\n\n

In other cases the values of aria-prefixed attributes are represented by strings<\/em>, numbers<\/em>, integers<\/em>, ID references<\/em> or true\/false<\/em> values.<\/p>\n\n\n\n

How to Make Use of ARIA States and Properties<\/h4>\n\n\n\n
1. Build Relationships Between Elements With Relationship Attributes<\/h5>\n\n\n\n

Use relationship attributes<\/a> to indicate relationships between different elements on your site, that can\u2019t be otherwise determined from the document structure. For example the aria-labelledby<\/code> property identifies the element that labels the current element.<\/p>\n\n\n\n

aria-labelledby<\/code> \u2013 among many other things<\/a> \u2013 can bind headings to ARIA landmark regions in the following way:<\/p>\n\n\n\n

1234567<\/td><<\/code>div<\/code> role<\/code>=<\/code>\"main\"<\/code> aria-labelledby<\/code>=<\/code>\"some-id\"<\/code>><\/code> <<\/code>h1<\/code> id<\/code>=<\/code>\"some-id\"<\/code>>This Is A Heading<\/<\/code>h1<\/code>><\/code> Main content...<\/code> <\/<\/code>div<\/code>><\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
2. Synchronize States and Properties With The Element\u2019s Lifecycle<\/h5>\n\n\n\n

After you set an ARIA landmark role for a perceivable area on your HTML page, it can help assistive technologies a lot if you change the ARIA-prefixed states and properties of child elements in accordance with events happening on the screen.<\/p>\n\n\n\n

This can be crucial where users have to interact with the site, for example filling in a form or running a search query.<\/p>\n\n\n\n

3. Match The Visual and The Accessible Interfaces<\/h5>\n\n\n\n

The general rule of thumb of accessibility design is that the current state of the user interface always needs to be perceivable by assistive technologies. For instance if the user chooses an option in a form, it needs to appear selected for assistive technologies too.<\/p>\n\n\n\n

This can be easily achieved by utilizing the aria-selected<\/a> state with the following syntax: <option aria-selected=\"true\"><\/option><\/code>.<\/p>\n\n\n\n

W3C\u2019s WAI-ARIA Authoring Practices<\/a> guideline can give you many other great ideas about how to properly harmonize the visual and the accessible interfaces of your site.<\/p>\n\n\n\n

Don\u2019t Overuse ARIA<\/h4>\n\n\n\n

Using ARIA roles and attributes sometimes can be redundant. When you use semantic tags of HTML5 such as <button><\/button><\/code> or <form><\/form><\/code>, modern web browsers add the appropriate ARIA semantics by default. In this case it has no sense to separately set the ARIA landmark roles.<\/p>\n\n\n\n

For example it\u2019s unnecessary to use the form<\/strong> landmark role to define the <form><\/code> element. Instead of the <form role=\"form\"><\/form><\/code> syntax it\u2019s perfectly enough to use just <form><\/form><\/code>. It\u2019s also superfluous to use HTML\u2019s native attributes along with the appropriate ARIA attribute.<\/p>\n\n\n\n

So if you\u2019ve already added the hidden<\/strong> HTML attribute to a form input, it\u2019s unnecessary to add the aria-hidden<\/strong> state, as the browser includes it by default.<\/p>\n","protected":false},"excerpt":{"rendered":"

A truly open and inclusive web needs technologies that allow disabled users relying on assistive technologies to enjoy dynamic web content and modern web apps. W3C\u2019s accessibility web standards aim to populate the web with Accessible Rich Internet Applications (ARIA) that users with disabilities can efficiently use. ARIA is one of the numerous\u00a0accessibility standards and guidelines\u00a0published by […]<\/p>\n","protected":false},"author":2,"featured_media":5617,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[77],"tags":[73],"jetpack_featured_media_url":"https:\/\/azoora.com\/blog\/wp-content\/uploads\/2020\/10\/open-web-platform.jpg","jetpack_publicize_connections":[],"jetpack_shortlink":"https:\/\/wp.me\/p7FQPL-1sz","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts\/5615"}],"collection":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/comments?post=5615"}],"version-history":[{"count":1,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts\/5615\/revisions"}],"predecessor-version":[{"id":5618,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/posts\/5615\/revisions\/5618"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/media\/5617"}],"wp:attachment":[{"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/media?parent=5615"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/categories?post=5615"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/azoora.com\/blog\/wp-json\/wp\/v2\/tags?post=5615"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}