The high school where I studied legal command had a nice, low-slope ramp built next to the main entrance. As far as I can remember, I didn’t really see a wheelchair student at school, I was weird about it all. Later, I often used the ramp instead of the stairs for fun in the morning, and on one such occasion — I was amazed myself that it hadn’t appeared until then — I realized I had to walk through a wide, gravel-filled bed of gravel to get to the ramp. If only someone hadn’t wanted to go up with some wheelchair tractor, they would have definitely got stuck in the gravel. (Luckily, over the years, the previous gravel section has been demolished, I trust, because they recognized the problem.)
The example is a good illustration of how we, who are not prevented from making life easier for those in difficulty, approach: if the law states that there should be some kind of help for them, we are forced to do it, but only strictly literally. Here is your ramp, leave me alone now! Not good? What else should I have? You don't even use it. Yeah, how come you don't know? You're not even trying! You keep demanding, and then you just look for excuses!
Making a website accessible requires as much thought as placing a ramp well, and the analogy stops that it would have been better for everyone to build the whole building so that it is accessible from the outset. But once it’s done, it can only be achieved with a lot of modifications to make it as usable as possible.
But the first step is to really approach it so that it can be used, not just wanting to know our legal obligations. When I was given the task of making the website of the Hungarian National Museum accessible (since the website of state-run organizations is accessible by law) and I read it for the first time in the JAWS program, I felt like walking through the gravel I understood how inaccessible the ramp. The machine began to grind through the content of the page in a wooden voice: following the elements with my eyes, of course I understood which part of the text read to which it belonged, but if I closed my eyes I found myself in a postmodern poem. The information flowed without structure, which is less fortunate for a website.
In the beginning, I was painfully ground in my postmodern world, as the official descriptions at first only provide guidelines similar to legal bick language ( https://www.w3.org/WAI/standards-guidelines/wcag/ ), on the other hand, many descriptions or blogs with more useful tips are also very lists general cases. But what do I do here right now with this particular menu? The whole design can’t be kicked up and in the meantime it’s still clear “Guideline” that roles = ‘navigation’ need to be put on the menus, but we have a big drop-down mega-menu that also has small image-raising blocks with current exhibits embedded in it. How can you walk through it intelligibly so that no one gets confused?
The solution ultimately consisted of a combination of many smaller technologies: instead of “hovering” with the mouse, the menu is opened with a hidden, keyboard-clickable link that is only perceived by the reader, and the small image recommenders separately - again only for the reader ” visible ”blocks.
The barrier-free picture, as in the case of the school, is made up of many small ramps and gravel bed disappearances, and most importantly, we try to figure out what technology would help if we happened to be able to navigate a page just by hearing. From these tips, I’ve gathered below a bunch, the ones that caused me the most headaches, and the ones I found most useful. My most useful sources of information were: the official documentation of W3ORG , the blog of Leonie Watson and Csaba Árpádházy-Godó, to whom I would like to thank you again for your time and valuable help.
Departures
Install JAWS , the most common reader in Hungary . Unfortunately, only the Windows version is available. But it’s also good to try basic things with Mac’s pre-installed Voice Over. Learning to manage programs may require a small investment of time, but we will be forced to master at least the most basic keyboard shortcuts to test barrier-free navigation.
For more details, see:
Voice Over: https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts
JAWS: https://webaim.org/resources/shortcuts/jaws
Aria-label and role attributes
One of the most basic technologies is to provide the site with “aria-labels”. The point is that the html has the optimal amount of extra meta-information. These are mainly given by the aria and role attributes. Basically, I applied the common sense rule that if something couldn’t be interpreted read aloud on its own, put aria-label = "this thing this and that" on it. The text can be anything, but it’s worth finding a balance between over-explanation and too little information.
Tip: you should pay attention to the links (<a> tags), because if there is no text between <a> and </a> (or some very complex <div>s between them), it will read the href, which sounds pretty comical. To avoid this, put an aria-label on such <a>s.
Roles are predefined and can be selected from: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles
The special ability of roles is that html elements can be converted to other types of elements for the reader. For example, if you put 'role' = 'article' on a <div>, it is like having an <article> tag.
Conversion to 'heading' can also be useful, here the level must be specified with a separate attribute. For example, <div role = "heading" aria-level = "1"> This is a headline </div> as if it were <h1>.
Visual hiding
Many times you need to keep something from appearing on the page, but you want the screen reader to still read it. Make sure that they are not hidden with display: none, because it is not consistently read. (Possible solutions: font-size: 0 or position: absolute; left: -10000px;)
Semantic tags
You may want to use the <navigation>, <article> tags. The program reads that a navigation block or article starts here and here, and also when it ends, it lets users know that these things belong together. The <header>, <footer>, <aside> tags also do a good job of helping us understand where we are on the site.
Headingek
It is important to provide headings. These allow you to quickly find the parts of the page you want. If the page layout is more visual or for some other reason there are no <h> elements, you may want to insert invisible h2-h3 elements or use the method mentioned above to <h> element other types of elements.
Hide / convert links
Sometimes it is necessary to prevent a visible link from being read, in which case the following attributes must be provided: tabIndex = "- 1" aria-hidden = "true"
The reverse of this is that we have a non-clickable element for link-like behavior by adding the role = ”link” tabindex = “0” attributes. These can even be manipulated from JavaScript.
What do we do if something is really not where it should be? Aria-owns.
For example, if you have a menu that has a submenu very far in the DOM, how do you get the reader to respect what submenu you want after the main menu item to read? Put the aria-owns attribute on the main menu item and it will be as if the submenu in the DOM is also a child item.
<ul> <li aria-owns="child">Fruit</li> <li>Vegetables</li> </ul> <ul id="child"> <li>Apples</li> <li>Bananas</li> </ul>
That is, as if in the DOM:
<ul>
<li>Fruit
<ul>
<li>Apples</li>
<li>Bananas</li>
</ul>
</li>
<li>Vegetables</li>
</ul>
Chosen
Using the Chosen library to make select fields more exciting can be a headache by hiding the original <select>s with display: none, even though readers can handle it perfectly, but they can't handle the elements Chosen puts. But nothing is wrong: just change the hide from css so that instead of display: none it is only visually hidden e.g.
.chosen-processed {
display: block !important;
width: 1px;
height: 1px;
color: transparent;
background-color: transparent;
border: 0;
padding: 0;
}
Dynamic menus
For dynamic menus, basically this technique should be used. However, some tangles can easily occur if the visual appearance is more complex.
- Care should be taken to ensure that visually impaired visitors cannot crawl. They have to navigate with the keyboard and "click" with the given key combination of the reader to open a menu item. If the original visual operation is not like this, a compromise must be found, such as opening a hover and a click.
- When we hide submenus often, however, the program will still want to read them. For example, when they are not hidden with display: none, but with some animation they are set to height: 0. Then tabIndex = "- 1" aria-hidden = "true" can help
- It is also possible to mark the active menu item: aria-current = "page" must be added to the given link. (For me, this did not result in any other scanned information in any of the readers, but I may be the only one misusing it.)
- Sometimes the focus is not shifted to the right place. For example, you want reading to continue at a certain point in the item you just opened. In this case, use the focus () JavaScript function in the appropriate place.
- For sidebar menus, you may need to open and close with a small <i> element. It can be solved that the reader reads these as if they were a link by providing them with attributes role = ”link” tabindex = “0”. (We also use the aria-expanded attributes for such elements)
- It is also advisable to trigger the closing of the menus by pressing the “esc” key. E.g.
$(document).on('keyup', function (evt) {
if (evt.keyCode === 27) {
closeMegaMenu();
}
}
Share with your friends!