Secure web accessibility of HTML5 semantic areas through WAI-ARIA roles
As you know, HTML5 has advanced semantic layout. It allows you to wrap individual logical blocks of the page into block tags specifically designed for them, such as header, main, footer, and others. But the improvement of the structural and semantic layout, as a rule, automatically contributes to increasing the level of accessibility of the web-interface for users of screen access programs, because they add page elements that can be navigated and quickly moved between blocks of content.
In principle, additional markup to ensure accessibility is implemented through a separate WAI-ARIA technology, however, the standard HTML5 semantic structures with modern browsers and modern screen access programs are perceived as the corresponding ARIA attributes for assistive technologies. Simply put, this means that in theory the following two versions of the layout are similar in terms of screen reader programs:
Listing 1:
')
Since, throughout the article, we are only interested in what happens in the body container, then we will further agree that the subsequent listings will cite only the body layout, and everything else will be implied as in Listing 1.)
Listing 2:
So, Listing 1 is laid out using standard HTML5 semantic features, and Listing 2 uses the good old block layout through a div, but with the addition of WAI-ARIA markup. As conceived by the developers of accessibility standards, browsers and assistive technologies, it is assumed that these two pages should be handled by screen access programs in the same way, but here we are faced with the prose of life.
Take the two most popular screen access programs: JAWS (version 15.0) and NVDA (version 2014.3), as well as the two most popular browsers among their users: Internet Explorer (version 11) and Firefox (version 32). After that, we will test all possible configurations for processing the semantic areas from Listing 1. As a result, we get the following results:
It turns out that everything works far from what is supposed to be theoretically. And with the decrease of software versions, the support of some structures may start to fall off unevenly. And the main thing in official manuals and technical standards is unlikely to be read, and only experienced and meticulous QA-engineer accessibility, which is not in every very large project, can reveal such problems, let it be accessible and spelled out in TK, for example, in the case of development of socially oriented or state sites, as well as in projects for which accessibility is implied as a competitive advantage, for example, Internet banking. About projects not focused on accessibility and can not speak.
Of course, since the final version of WAI-ARIA was adopted quite recently , and the guide for its support from the User Agent in general still does not exist in its final form, then in the future, when everything is settled, we can hope that such things will also be unified. However, projects are being developed and rented out here and now, and nobody has canceled graceful degradation either. Therefore, it makes sense to impose so that on the one hand to use the semantic novelties of HTML5, and on the other - not to offend assistive technologies in any case.
This can be achieved by using both HTML5 semantics and WAI-ARIA markup at the same time. That is, you will need to add the corresponding WAI-ARIA roles to these tags, as if securing HTML5 semantic areas through Accessible Rich Internet Applications.
Here you should immediately warn that the WAI-ARIA markup attributes have a higher priority than standard HTML5 semantic structures, so if, for example, for the main tag you enter the role attribute with the value of contentinfo, then screen access programs will call it as if it were footer . So the absence of WAI-ARIA is better than the presence of its incorrect use. In other words: “You can’t do it, don’t fight it,” but this article is intended to teach this not complicated layout technique.
By and large, it all comes down to the need to learn the correct match between WAI-ARIA roles and standard HTML5 semantic structures. In principle, from Listings 1 and 2, the main matches are already clear:
By the way, with regard to the role of the banner, we specifically make a reservation that it is intended for wrapping up the entire page header, and not the advertising banner. That is, it is, indeed, a direct analogue of the header tag. As practice shows, some of the word “banner” is misleading, and they begin to assign this value to advertising banners, but this is wrong.
The above correspondences will correctly mark out the basic HTML5 semantic areas in WAI-ARIA. However, it is noticeable that not all of them are mentioned there. The fact is that, firstly, some HTML5 semantic structures do not have direct analogs to WAI-ARIA, for example, this concerns the article tag, and secondly, with some of them, things are not so simple, mainly speech, of course, aside.
By default, the aside tag is interpreted by screen access programs as analogous to the complementary role. In principle, in most cases this should be the case, however, the range of possible applications for aside is quite large, so situations may arise where the role of the complementary is not very appropriate.
Frankly, here we are already entering into quite thin ice flavors and a subjective understanding of the design of non-visual interfaces, where the discussions roughly correspond to a dispute over fonts or color schemes in the world of visual interfaces. Nevertheless, we still give one example to give an idea about this aspect.
Listing 3:
The complementary role describes for the screen-access program an interface block as a section with some additional information that is not directly related to the main content. However, in our example, we distinguish two such blocks: at the level of the entire page, in which we wrap the navigation bar, and also inside the main content, where we wrap the tags. Obviously, these are essentially very different blocks with additional information, so we assigned the role of note to the second, which marks the block as a segment with some kind of note.
The use of such methods of layout requires a somewhat greater understanding of the logic of non-visual interfaces, so you should not cut it off your shoulder. You can only advise to still use the role of the complementary, and use more complex interface moves only if you are sufficiently confident that this is appropriate. If complementary was used in Listing 3 instead of note, this would be better than the other way around.
By the way, the role of note has no direct analog among the semantic tags of HTML5, therefore there is no full compatibility in one or the other. Such roles and screen access programs are handled a little differently, so it’s generally better not to get involved with them if the project does not have serious accessibility specialists who understand all the pitfalls.
In addition, the problem of using several identical HTML5 semantic areas can be solved in another way, namely by adding explanatory labels to them. For example, if there are several navigation bars in the interface, it makes sense to indicate their purpose, so that the user of the screen access program immediately understands the difference.
Listing 4:
That is, the aria-label attribute allows you to specify an additional text label that will explain the purpose of this block. Moreover, it is important to understand that aria-label complements the role, so you don’t need to duplicate information about the semantic purpose of the block in its text, for example, you don’t need to write to nav that it’s “Navigating by section”, simply write “Sections”. Well, for the main tag there is generally no need to prescribe aria-label, since in principle it should be on the page only in a single copy and its purpose is clear. But for aside, footer, header or nav, an explanatory label should be added as appropriate. As a rule, it makes sense if there are several such elements of the same type on the page, which is not so common with the same footer or header.
Compliance with the simple layout techniques described in this article will allow you to create interfaces that are not just accessible, but equally accessible under all basic configurations. And most importantly, all this will absolutely not break the visual layout, because the role and aria-label attributes only affect how the page is represented by screen access programs through speech or tactile information output.
Finally, two links where you can learn more about the semantic features of HTML5 and WAI-ARIA:
In principle, additional markup to ensure accessibility is implemented through a separate WAI-ARIA technology, however, the standard HTML5 semantic structures with modern browsers and modern screen access programs are perceived as the corresponding ARIA attributes for assistive technologies. Simply put, this means that in theory the following two versions of the layout are similar in terms of screen reader programs:
Listing 1:
<!DOCTYPE html> <html lang="ru"> <head> <meta charset="utf-8"> <title> 1</title> <!--[if lt IE 9]> <script type="text/javascript"> var e = ("aside,footer,header,main,nav").split(','); for (var i = 0; i < e.length; i++) { document.createElement(e[i]); } </script> <![endif]--> </head> <body> <header> </header> <aside> <nav> </nav> </aside> <main> </main> <footer> </footer> </body> </html> ')
Since, throughout the article, we are only interested in what happens in the body container, then we will further agree that the subsequent listings will cite only the body layout, and everything else will be implied as in Listing 1.)
Listing 2:
<div role="banner"> </div> <div role="complementary"> <div role="navigation"> </div> </div> <div role="main"> </div> <div role="contentinfo"> </div> So, Listing 1 is laid out using standard HTML5 semantic features, and Listing 2 uses the good old block layout through a div, but with the addition of WAI-ARIA markup. As conceived by the developers of accessibility standards, browsers and assistive technologies, it is assumed that these two pages should be handled by screen access programs in the same way, but here we are faced with the prose of life.
Take the two most popular screen access programs: JAWS (version 15.0) and NVDA (version 2014.3), as well as the two most popular browsers among their users: Internet Explorer (version 11) and Firefox (version 32). After that, we will test all possible configurations for processing the semantic areas from Listing 1. As a result, we get the following results:
| Tags | Jaws Internet Explorer | Jaws Firefox | Nvda Internet Explorer | Nvda Firefox |
|---|---|---|---|---|
| aside | Yes | Yes | Not | Yes |
| footer | Not | Yes | Not | Yes |
| header | Not | Yes | Not | Yes |
| main | Yes | Yes | Not | Yes |
| nav | Yes | Yes | Not | Yes |
It turns out that everything works far from what is supposed to be theoretically. And with the decrease of software versions, the support of some structures may start to fall off unevenly. And the main thing in official manuals and technical standards is unlikely to be read, and only experienced and meticulous QA-engineer accessibility, which is not in every very large project, can reveal such problems, let it be accessible and spelled out in TK, for example, in the case of development of socially oriented or state sites, as well as in projects for which accessibility is implied as a competitive advantage, for example, Internet banking. About projects not focused on accessibility and can not speak.
Of course, since the final version of WAI-ARIA was adopted quite recently , and the guide for its support from the User Agent in general still does not exist in its final form, then in the future, when everything is settled, we can hope that such things will also be unified. However, projects are being developed and rented out here and now, and nobody has canceled graceful degradation either. Therefore, it makes sense to impose so that on the one hand to use the semantic novelties of HTML5, and on the other - not to offend assistive technologies in any case.
This can be achieved by using both HTML5 semantics and WAI-ARIA markup at the same time. That is, you will need to add the corresponding WAI-ARIA roles to these tags, as if securing HTML5 semantic areas through Accessible Rich Internet Applications.
Here you should immediately warn that the WAI-ARIA markup attributes have a higher priority than standard HTML5 semantic structures, so if, for example, for the main tag you enter the role attribute with the value of contentinfo, then screen access programs will call it as if it were footer . So the absence of WAI-ARIA is better than the presence of its incorrect use. In other words: “You can’t do it, don’t fight it,” but this article is intended to teach this not complicated layout technique.
By and large, it all comes down to the need to learn the correct match between WAI-ARIA roles and standard HTML5 semantic structures. In principle, from Listings 1 and 2, the main matches are already clear:
| HTML5 tag | WAI-ARIA Role |
|---|---|
| footer | contentinfo |
| header | banner |
| main | main |
| nav | navigation |
By the way, with regard to the role of the banner, we specifically make a reservation that it is intended for wrapping up the entire page header, and not the advertising banner. That is, it is, indeed, a direct analogue of the header tag. As practice shows, some of the word “banner” is misleading, and they begin to assign this value to advertising banners, but this is wrong.
The above correspondences will correctly mark out the basic HTML5 semantic areas in WAI-ARIA. However, it is noticeable that not all of them are mentioned there. The fact is that, firstly, some HTML5 semantic structures do not have direct analogs to WAI-ARIA, for example, this concerns the article tag, and secondly, with some of them, things are not so simple, mainly speech, of course, aside.
By default, the aside tag is interpreted by screen access programs as analogous to the complementary role. In principle, in most cases this should be the case, however, the range of possible applications for aside is quite large, so situations may arise where the role of the complementary is not very appropriate.
Frankly, here we are already entering into quite thin ice flavors and a subjective understanding of the design of non-visual interfaces, where the discussions roughly correspond to a dispute over fonts or color schemes in the world of visual interfaces. Nevertheless, we still give one example to give an idea about this aspect.
Listing 3:
<header role="banner"> </header> <aside role="complementary"> <nav role="navigation"> </nav> </aside> <main role="main"> <aside role="note"> </aside> </main> <footer role="contentinfo"> </footer> The complementary role describes for the screen-access program an interface block as a section with some additional information that is not directly related to the main content. However, in our example, we distinguish two such blocks: at the level of the entire page, in which we wrap the navigation bar, and also inside the main content, where we wrap the tags. Obviously, these are essentially very different blocks with additional information, so we assigned the role of note to the second, which marks the block as a segment with some kind of note.
The use of such methods of layout requires a somewhat greater understanding of the logic of non-visual interfaces, so you should not cut it off your shoulder. You can only advise to still use the role of the complementary, and use more complex interface moves only if you are sufficiently confident that this is appropriate. If complementary was used in Listing 3 instead of note, this would be better than the other way around.
By the way, the role of note has no direct analog among the semantic tags of HTML5, therefore there is no full compatibility in one or the other. Such roles and screen access programs are handled a little differently, so it’s generally better not to get involved with them if the project does not have serious accessibility specialists who understand all the pitfalls.
In addition, the problem of using several identical HTML5 semantic areas can be solved in another way, namely by adding explanatory labels to them. For example, if there are several navigation bars in the interface, it makes sense to indicate their purpose, so that the user of the screen access program immediately understands the difference.
Listing 4:
<header role="banner"> </header> <aside role="complementary" aria-label=" "> <nav role="navigation" aria-label=" "> </nav> <nav role="navigation" aria-label=""> </nav> </aside> <aside role="complementary" aria-label=""> </aside> <main role="main"> <aside role="complementary" aria-label=""> </aside> </main> <footer role="contentinfo"> </footer> That is, the aria-label attribute allows you to specify an additional text label that will explain the purpose of this block. Moreover, it is important to understand that aria-label complements the role, so you don’t need to duplicate information about the semantic purpose of the block in its text, for example, you don’t need to write to nav that it’s “Navigating by section”, simply write “Sections”. Well, for the main tag there is generally no need to prescribe aria-label, since in principle it should be on the page only in a single copy and its purpose is clear. But for aside, footer, header or nav, an explanatory label should be added as appropriate. As a rule, it makes sense if there are several such elements of the same type on the page, which is not so common with the same footer or header.
Compliance with the simple layout techniques described in this article will allow you to create interfaces that are not just accessible, but equally accessible under all basic configurations. And most importantly, all this will absolutely not break the visual layout, because the role and aria-label attributes only affect how the page is represented by screen access programs through speech or tactile information output.
Finally, two links where you can learn more about the semantic features of HTML5 and WAI-ARIA:
Source: https://habr.com/ru/post/240065/
All Articles