Reading in a Web Browser Best Practices
Treatment common accessibility problems
Next nosotros plough our attention to accessibility, providing information on common issues, how to exercise simple testing, and how to make use of auditing/automation tools for finding accessibility problems.
| Prerequisites: | Familiarity with the cadre HTML, CSS, and JavaScript languages; an thought of the loftier level principles of cross browser testing. |
|---|---|
| Objective: | To be able to diagnose mutual Accessibility bug, and utilize appropriate tools and techniques to fix them. |
What is accessibility?
When nosotros say accessibility in the context of web engineering science, virtually people immediately think of making sure websites/apps are usable by people with disabilities, for example:
- Visually impaired people using screen readers or magnification/zoom to admission text
- People with motor office impairments using the keyboard (or other non-mouse features) to activate website functionality.
- People with hearing impairments relying on captions/subtitles or other text alternatives for sound/video content.
However, information technology is wrong to say that accessibility is just about disabilities. Really, the aim of accessibility is to make your websites/apps usable past as many people in every bit many contexts as possible, not just those users using high-powered desktop computers. Some examples might include:
- Users on mobile devices.
- Users on alternative browsing devices such as TVs, watches, etc.
- Users of older devices that might not have the latest browsers.
- Users of lower spec devices that might have irksome processors.
In a way, this whole module is about accessibility — cross browser testing makes sure that your sites can exist used by as many people as possible. What is accessibility? defines accessibility more completely and thoroughly than this commodity does.
That said, this article will cover cantankerous browser and testing issues surrounding people with disabilities, and how they use the Web. We've already talked about other spheres such as responsive design and operation in other places in the module.
Notation: Like many things in web development, accessibility isn't about 100% success or non; 100% accessibility is pretty much incommunicable to accomplish for all content, especially equally sites become more than circuitous. Instead, it is more than well-nigh making a reasonable attempt to make as much of your content accessible to every bit many people as possible via defensive coding and sticking to best practices.
Common accessibility issues
In this section we'll detail some of the chief issues that arise around spider web accessibility, connected with specific technologies, along with best practices to follow, and some quick tests you lot can do to see if your sites are going in the right direction.
Notation: Accessibility is morally the right thing to exercise, and good for business (numbers of disabled users, users on mobile devices, etc. present significant market segments), only information technology is also a legal requirement in many parts of the world to make web content accessible to people with disabilities. Read Accessibility guidelines and the law for more than information.
HTML
Semantic HTML (where the elements are used for their correct purpose) is accessible right out of the box — such content is readable by sighted viewers (provided you don't practise anything silly like brand the text way also small or hibernate it using CSS), only will also be usable by assistive technologies similar screen readers (apps that literally read out a web page to their user), and confer other advantages too.
Semantic structure
The most of import quick win in semantic HTML is to use a construction of headings and paragraphs for your content; this is because screen reader users tend to utilize the headings of a certificate as signposts to observe the content they need more than quickly. If your content has no headings, all they volition get is a huge wall of text with no signposts to find annihilation. Examples of bad and good HTML:
<font size = "7" > My heading </font > <br > <br > This is the outset section of my document. <br > <br > I'll add together another paragraph hither also. <br > <br > <font size = "5" > My subheading </font > <br > <br > This is the starting time subsection of my document. I'd love people to exist able to observe this content! <br > <br > <font size = "5" > My 2nd subheading </font > <br > <br > This is the second subsection of my content. I think it is more than interesting than the final i. <h1 > My heading </h1 > <p > This is the first section of my document. </p > <p > I'll add another paragraph here too. </p > <h2 > My subheading </h2 > <p > This is the first subsection of my certificate. I'd love people to be able to observe this content! </p > <h2 > My 2nd subheading </h2 > <p > This is the second subsection of my content. I think it is more interesting than the final ane. </p > In addition, your content should brand logical sense in its source lodge — you can e'er identify information technology where you want using CSS subsequently on, but you should become the source order right to start with.
Every bit a examination, you can plow off a site'due south CSS and see how understandable it is without it. You could do this manually by just removing the CSS from your lawmaking, but the easiest manner is to use browser features, for example:
- Firefox: Select View > Page Manner > No Way from the main menu.
- Safari: Select Develop > Disable Styles from the main carte (to enable the Develop bill of fare, choose Safari > Preferences > Advanced > Show Develop card in card bar).
- Chrome: Install the Web Developer Toolbar extension, then restart the browser. Click the gear icon that will appear, and then select CSS > Disable All Styles.
- Edge: Select View > Fashion > No Style from the main carte.
Using native keyboard accessibility
Sure HTML features can be selected using only the keyboard — this is default behavior, bachelor since the early days of the spider web. The elements that have this adequacy are the common ones that allow user to interact with spider web pages, namely links, <button>s, and grade elements like <input>.
You lot can endeavour this out using our native-keyboard-accessibility.html example (see the source code) — open this in a new tab, and try pressing the tab key; after a few presses, you should run into the tab focus start to move through the different focusable elements; the focused elements are given a highlighted default style in every browser (information technology differs slightly betwixt dissimilar browsers) and then that you can tell what element is focused.
Y'all tin then printing Enter/Return to follow a focused link or press a button (we've included some JavaScript to brand the buttons warning a message), or start typing to enter text in a text input (other form elements have different controls, for example the <select> element can have its options displayed and cycled between using the upwards and down arrow keys).
Notation that different browsers may have different keyboard control options bachelor. Virtually modern browsers follow the tab blueprint described to a higher place (yous can also do Shift + Tab to move backwards through the focusable elements), but some browsers have their own idiosyncrasies:
- Firefox for the Mac doesn't practise tabbing by default. To turn it on, y'all accept to go to Preferences > Avant-garde > Full general, so uncheck "Ever apply the cursor keys to navigate within pages". Next, you lot have to open up your Mac's Arrangement Preferences app, then go to Keyboard > Shortcuts, and then select the All Controls radio button.
- Safari doesn't permit y'all to tab through links by default; to enable this, y'all need to open up Safari's Preferences, go to Advanced, and check the Press Tab to highlight each detail on a webpage checkbox.
Warning: You should perform this kind of examination/review on any new page you lot write — make sure that functionality can be accessed by the keyboard, and that the tab order provides a sensible navigation path through the document.
This example highlights the importance of using the correct semantic element for the correct job. It is possible to manner any element to look like a link or push button with CSS, and to behave similar a link or button with JavaScript, but they won't actually be links or buttons, and you'll lose a lot of the accessibility these elements give yous for gratis. And so don't do it if you can avoid it.
Another tip — as shown in our instance, you tin can control how your focusable elements look when focused, using the :focus pseudo-class. Information technology is a expert thought to double upwards focus and hover styles, so your users get that visual inkling that a control volition practise something when activated, whether they are using mouse or keyboard:
a:hover, input:hover, button:hover, select:hover, a:focus, input:focus, button:focus, select:focus { font-weight : bold; } Note: If you lot do decide to remove the default focus styling using CSS, brand sure you supersede it with something else that fits in with your blueprint better — it is a very valuable accessibility tool, and should not exist removed.
Building in keyboard accessibility
Sometimes information technology is not possible to avoid losing keyboard accessibility. Yous might have inherited a site where the semantics are not very expert (peradventure y'all've ended up with a horrible CMS that generates buttons made with <div>south), or you lot are using a complex control that does not take keyboard accessibility built in, like the HTML5 <video> chemical element (amazingly, Opera is the only browser that allows you to tab through the <video> chemical element'south default browser controls). You lot have a few options here:
- Create custom controls using
<button>elements (which nosotros can tab to by default!) and JavaScript to wire up their functionality. See Creating a cross-browser video player for some good examples of this. - Create keyboard shortcuts via JavaScript, so functionality is activated when you press certain keys on the keyboard. Encounter Desktop mouse and keyboard controls for some game-related examples that tin can exist adapted for whatsoever purpose.
- Use some interesting tactics to fake button behavior. Accept for instance our fake-div-buttons.html case (see source code). Here we've given our simulated
<div>buttons the ability to exist focused (including via tab) by giving each 1 the aspecttabindex="0"(meet WebAIM's tabindex article for more really useful details). This allows us to tab to the buttons, merely not to activate them via the Enter/Return central. To do that, we had to add the following bit of JavaScript trickery:Here we add a listener to thedocument. onkeydown = function ( e ) { if (e.keyCode === thirteen ) { // The Enter/Return key document.activeElement. onclick (due east) ; } } ;documentobject to detect when a push has been pressed on the keyboard. Nosotros check what push was pressed via the event object'south keyCode property; if it is the keycode that matches Return/Enter, nosotros run the role stored in the button'due southonclickhandler usingcertificate.activeElement.onclick().activeElementgives us the element that is currently focused on the page.
Note: This technique volition only work if you set your original effect handlers via event handler properties (e.chiliad. onclick). addEventListener won't work. This is a lot of extra hassle to build the functionality dorsum in. And there'due south bound to be other problems with it. Meliorate to just use the correct element for the right task in the first identify.
Text alternatives
Text alternatives are very important for accessibility — if a person has a visual or hearing impairment that stops them existence able to see or hear some content, and then this is a problem. The simplest text alternative available is the humble alt attribute, which nosotros should include on all images that contain relevant content. This should incorporate a description of the image that successfully conveys its meaning and content on the page, to be picked upwardly past a screenreader and read out to the user.
Missing alt text tin can be tested for in a number of ways, for instance using accessibility Auditing tools.
Alt text is slightly more complex for video and audio content. In that location is a way to ascertain text tracks (east.k. subtitles) and brandish them when video is existence played, in the form of the <track> chemical element, and the WebVTT format (run across Adding captions and subtitles to HTML5 video for a detailed tutorial). Browser compatibility for these features is adequately good, but if you lot desire to provide text alternatives for audio or support older browsers, a simple text transcript presented somewhere on the page or on a split folio might be a skilful idea.
Element relationships and context
There are sure features and best practices in HTML designed to provide context and relationships between elements where none otherwise exists. The iii virtually common examples are links, form labels, and data tables.
The key to accessible link text is that people using screen readers will often use a mutual feature whereby they pull upward a list of all the links on the folio. In this case, the link text needs to make sense out of context. For instance, a list of links labeled "click hither", "click me", etc. is really bad for accessibility. Information technology is better for link text to make sense in context and out of context.
Next on our list, the class <label> element is one of the central features that allows u.s.a. to make forms attainable. The trouble with forms is that you need labels to say what data should be entered into each form input. Each label needs to be included inside a <characterization> to link it unambiguously to its partner grade input (each <label> for aspect value needs to match the form element id value), and information technology will make sense fifty-fifty if the source order is not completely logical (which to be fair information technology should be).
Finally, a quick discussion about data tables. A basic data table can be written with very elementary markup (run across bad-table.html live, and source), only this has bug — there is no manner for a screen reader user to associate rows or columns together every bit groupings of information — to do this you need to know what the header rows are, and if they are heading up rows, columns, etc. This can only be done visually for such a table.
If you instead look at our punk-bands-complete.html example (live, source), you can see a few accessibility aids at work here, such as table headers (<th> and scope attributes), <explanation> chemical element, etc.
CSS
CSS tends to provide a lot fewer fundamental accessibility features than HTML, but it can notwithstanding exercise just as much harm to accessibility if used incorrectly. We accept already mentioned a couple of accessibility tips involving CSS:
- Use the correct semantic elements to mark up different content in HTML; if you desire to create a different visual result, use CSS — don't abuse an HTML element to become the look you want. For case, if you want bigger text, use
font-size, non an<h1>element. - Make sure your source order makes sense without CSS; y'all tin can ever utilize CSS to style the page any way you want afterward.
- You should make sure interactive elements like buttons and links have appropriate focus/hover/active states prepare, to give the user visual clues as to their function. If you remove the defaults for stylistic reasons, brand sure you lot include some replacement styles.
There are a few other considerations you should accept into account.
Colour and color dissimilarity
When choosing a color scheme for your website, you should make certain that the text (foreground) colour contrasts well with the background color. Your design might look cool, only information technology is no skilful if people with visual impairments like color blindness can't read your content. Use a tool like WebAIM'southward Color Contrast Checker to cheque whether your scheme is contrasting enough.
Another tip is to not rely on color lonely for signposts/data, equally this will be no practiced for those who tin can't run across the color. Instead of marking required form fields in red, for example, mark them with an asterisk and in red.
Note: A high contrast ratio volition also allow anyone using a smartphone or tablet with a glossy screen to meliorate read pages when in a bright environs, such equally sunlight.
Hiding content
There are many instances where a visual design will require that not all content is shown at in one case. For instance, in our Tabbed info box example (come across source code) we have iii panels of information, but we are positioning them on top of one another and providing tabs that tin exist clicked to bear witness each one (information technology is as well keyboard accessible — you can alternatively use Tab and Enter/Return to select them).
Screen reader users don't intendance virtually any of this — they are happy with the content as long as the source order makes sense, and they can go to it all. Accented positioning (equally used in this example) is generally seen as one of the best mechanisms of hiding content for visual effect, because it doesn't stop screen readers from getting to information technology.
On the other hand, yous shouldn't utilise visibility :hidden or display :none, because they practise hide content from screenreaders. Unless of course, there is a adept reason why you want this content to exist subconscious from screenreaders.
JavaScript
JavaScript has the same kind of problems as CSS with respect to accessibility — information technology can be disastrous for accessibility if used desperately, or overused. We've already hinted at some accessibility problems related to JavaScript, mainly in the area of semantic HTML — y'all should e'er utilize advisable semantic HTML to implement functionality wherever it is bachelor, for case use links and buttons as appropriate. Don't use <div> elements with JavaScript code to fake functionality if at all possible — it is error decumbent, and more than piece of work than using the free functionality HTML gives yous.
Simple functionality
By and large uncomplicated functionality should work with just the HTML in place — JavaScript should merely be used to enhance functionality, non build it in entirely. Skilful uses of JavaScript include:
- Providing customer-side form validation, which alerts users to problems with their form entries quickly, without having to wait for the server to check the data. If it isn't available, the form will still work, but validation might be slower.
- Providing custom controls for HTML5
<video>s that are accessible to keyboard-but users (as we said before, the default browser controls aren't keyboard-accessible in most browsers).
Note: WebAIM's Accessible JavaScript provides some useful farther details most considerations for accessible JavaScript.
More complex JavaScript implementations can create problems with accessibility — you demand to do what you can. For example, it would exist unreasonable to expect you to make a complex 3D game written using WebGL 100% accessible to a blind person, but you could implement keyboard controls so it is usable by non-mouse users, and make the color scheme contrasting plenty to be usable past those with color deficiencies.
Complex functionality
Ane of the main areas problematic for accessibility is circuitous apps that involve complicated form controls (such as date pickers) and dynamic content that is updated often and incrementally.
Non-native complicated form controls are problematic because they tend to involve a lot of nested <div>s, and the browser does not know what to exercise with them by default. If yous are inventing them yourself, you need to make certain that they are keyboard accessible; if yous are using some kind of third-party framework, carefully review the options available to see how accessible they are before diving in. Bootstrap looks to be fairly skilful for accessibility, for example, although Making Bootstrap a Petty More Accessible by Rhiana Heath explores some of its issues (mainly related to color contrast), and looks at some solutions.
Regularly updated dynamic content can exist a problem because screenreader users might miss it, especially if information technology updates unexpectedly. If you accept a single-page app with a main content panel that is regularly updated using XMLHttpRequest or Fetch, a screenreader user might miss those updates.
WAI-ARIA
Do yous need to utilise such circuitous functionality, or will plain old semantic HTML do instead? If you do demand complexity, you should consider using WAI-ARIA (Accessible Rich Cyberspace Applications), a specification that provides semantics (in the grade of new HTML attributes) for items such as complex form controls and updating panels that can exist understood by near browsers and screen readers.
To deal with complex class widgets, you need to utilize ARIA attributes like roles to state what role different elements take in a widget (for example, are they a tab, or a tab panel?), aria-disabled to say whether a control is disabled or non, etc.
To deal with regularly updating regions of content, you can use the aria-live attribute, which identifies an updating region. Its value indicates how urgently the screen reader should read information technology out:
-
off:The default. Updates should not be appear. -
polite: Updates should be announced only if the user is idle. -
assertive: Updates should be appear to the user as soon as possible. -
rude: Updates should be appear straight abroad, even if this interrupts the user.
Here's an example:
<p > <span id = "LiveRegion1" aria-alive = "polite" aria-atomic = "imitation" > </span > </p > You can run into an example in action at Freedom Scientific's ARIA (Accessible Rich Internet Applications) Live Regions example — the highlighted paragraph should update its content every 10 seconds, and a screenreader should read this out to the user. ARIA Live Regions - Atomic provides another useful example.
Nosotros don't take space to cover WAI-ARIA in detail here, you can learn a lot more than about it at WAI-ARIA nuts.
Now we've covered accessibility considerations for dissimilar web technologies, including a few testing techniques (similar keyboard navigation and color dissimilarity checkers), let'south have a look at other tools yous can brand use of when doing accessibility testing.
Auditing tools
There are a number of auditing tools available that you tin can feed your spider web pages into. They will wait over them and return a listing of accessibility issues present on the page. Examples include:
- Moving ridge: A rather squeamish online accessibility testing tool that accepts a web address and returns a useful annotated view of that page with accessibility problems highlighted.
- Tenon: Another overnice online tool that goes through the code at a provided URL and returns results on accessibility errors including metrics, specific errors along with the WCAG criteria they affect, and suggested fixes. Information technology requires a free trial signup to view the results.
- tota11y: An accessibility tool from the Khan Academy that takes the form of a JavaScript library that you attach to your page to provide a number of accessibility tools.
Permit'south look at an example, using Moving ridge.
- Become to the Wave homepage.
- Enter the URL of our bad-semantics.html example into the text input box nigh the top of the page. Then press enter or click/tap the arrow at the far right edge of the input box.
- The site should respond with a clarification of the accessibility problems. Click the icons displayed to encounter more information about each of the issues identified by Moving ridge's evaluation.
Note: Such tools aren't expert enough to solve all your accessibility issues on their own. Y'all'll need a combination of these, knowledge and experience, user testing, etc. to get a full picture.
Automation tools
Deque's aXe tool goes a scrap farther than the auditing tools nosotros mentioned to a higher place. Like the others, information technology checks pages and returns accessibility errors. Its most immediately useful class is probably the browser extensions:
- aXe for Chrome
- aXe for Firefox
These add an accessibility tab to the browser developer tools. For example, we installed the Firefox version, so used it to inspect our bad-table.html example. We got the post-obit results:
aXe is also installable using npm, and can be integrated with task runners similar Grunt and Gulp, automation frameworks like Selenium and Cucumber, unit testing frameworks like Jasmine, and more besides (once more, see the chief aXe page for details).
Screenreaders
It is definitely worth testing with a screenreader to become used to how severely visually impaired people use the Web. There are a number of screenreaders available:
- Some are paid-for commercial products, like JAWS (Windows) and Window Eyes (Windows).
- Some are free products, like NVDA (Windows), ChromeVox (Chrome, Windows, and Mac Os X), and Orca (Linux).
- Some are built into the operating system, like VoiceOver (Mac OS Ten and iOS), ChromeVox (on Chromebooks), and TalkBack (Android).
Generally, screen readers are separate apps that run on the host operating system and tin can read non only spider web pages, but text in other apps every bit well. This is non ever the case (ChromeVox is a browser extension), only unremarkably. Screenreaders tend to act in slightly dissimilar ways and have different controls, so you'll have to consult the documentation for your called screen reader to become all of the details — saying that, they all work in basically the same sort of mode.
Let's go through some tests with a couple of different screenreaders to give you a full general idea of how they piece of work and how to test with them.
VoiceOver
VoiceOver (VO) comes free with your Mac/iPhone/iPad, so it's useful for testing on desktop/mobile if y'all use Apple products. We'll be testing it on Mac OS X on a MacBook Pro.
To turn it on, press Cmd + F5. If you've not used VO before, y'all will be given a welcome screen where you can choose to start VO or non, and run through a rather useful tutorial to learn how to use it. To plow it off over again, press Cmd + F5 again.
Note: You should go through the tutorial at to the lowest degree once — it is a really useful way to larn VO.
When VO is on, the display will look mostly the aforementioned, just you'll see a black box at the bottom left of the screen that contains information on what VO currently has selected. The current selection will also be highlighted, with a black border — this highlight is known every bit the VO cursor.
To use VO, you will make a lot of use of the "VO modifier" — this is a key or key combination that you lot need to press in addition to the actual VO keyboard shortcuts to get them to work. Using a modifier like this is common with screenreaders, to enable them to keep their commands from clashing with other commands. In the example of VO, the modifier tin can either be CapsLock, or Ctrl + Option.
VO has many keyboard commands, and we won't list them all here. The basic ones you lot'll need for spider web page testing are in the following table. In the keyboard shortcuts, "VO" means "the VoiceOver modifier".
| Keyboard shortcut | Clarification |
|---|---|
| VO + Cursor keys | Motility the VO cursor upward, right, downward, left. |
| VO + Spacebar | Select/activate items highlighted by the VO cursor. This includes items selected in the Rotor (see beneath). |
| VO + Shift + down cursor | Move into a group of items (such as an HTML tabular array, or a grade, etc.) One time inside a grouping you can move around and select items inside that grouping using the above commands equally normal. |
| VO + Shift + up cursor | Movement out of a group. |
| VO + C | (when inside a table) Read the header of the electric current cavalcade. |
| VO + R | (when within a tabular array) Read the header of the current row. |
| VO + C + C (ii Cs in succession) | (when inside a tabular array) Read the entire current column, including header. |
| VO + R + R (two Rs in succession) | (when inside a tabular array) Read the entire current row, including the headers that correspond to each prison cell. |
| VO + left cursor, VO + right cursor | (when within some horizontal options, such as a date or time picker) Move betwixt options. |
| VO + up cursor, VO + down cursor | (when inside some horizontal options, such as a appointment or time picker) Change the current selection. |
| VO + U | Use the Rotor, which displays lists of headings, links, class controls, etc. for easy navigation. |
| VO + left cursor, VO + correct cursor | (when inside Rotor) Move between different lists available in the Rotor. |
| VO + up cursor, VO + down cursor | (when inside Rotor) Movement between dissimilar items in the current Rotor list. |
| Esc | (when within Rotor) Exit Rotor. |
| Ctrl | (when VO is speaking) Pause/Resume spoken language. |
| VO + Z | Restart the last flake of speech communication. |
| VO + D | Go into the Mac'south Dock, and so you can select apps to run inside information technology. |
This seems like a lot of commands, but it isn't so bad when you lot get used to information technology, and VO regularly gives you reminders of what commands to use in certain places. Have a play with VO now; you lot tin can so proceed to play with some of our examples in the Screenreader testing section.
NVDA
NVDA is Windows-only, and you'll need to install information technology.
- Download it from nvaccess.org. You can choose whether to brand a donation or download it for costless; yous'll also need to requite them your electronic mail address before you can download information technology.
- In one case downloaded, install it — you double click the installer, accept the license and follow the prompts.
- To start NVDA, double click on the program file/shortcut, or apply the keyboard shortcut Ctrl + Alt + N. Y'all'll come across the NVDA welcome dialog when you start it. Here you can choose from a couple of options, and so printing the OK button to get going.
NVDA volition now exist active on your computer.
To utilize NVDA, yous volition make a lot of utilise of the "NVDA modifier" — this is a key that you need to printing in addition to the actual NVDA keyboard shortcuts to get them to piece of work. Using a modifier similar this is common with screenreaders, to enable them to go along their commands from clashing with other commands. In the instance of NVDA, the modifier tin either be Insert (the default), or CapsLock (can exist called past checking the start checkbox in the NVDA welcome dialog before pressing OK).
Annotation: NVDA is more subtle than VoiceOver in terms of how it highlights where it is and what information technology is doing. When y'all are scrolling through headings, lists, etc., items you are selected on will more often than not exist highlighted with a subtle outline, merely this is not always the case for all things. If you get completely lost, you can press Ctrl + F5 to refresh the current page and brainstorm from the acme again.
NVDA has many keyboard commands, and nosotros won't list them all here. The basic ones yous'll demand for spider web folio testing are in the following table. In the keyboard shortcuts, "NVDA" means "the NVDA modifier".
| Keyboard shortcut | Description |
|---|---|
| NVDA + Q | Turn NVDA off once more later yous've started it. |
| NVDA + up cursor | Read the current line. |
| NVDA + down cursor | Start reading at the current position. |
| Upward cursor and downward cursor, or Shift + Tab and Tab | Move to previous/next item on page and read it. |
| Left cursor and right cursor | Motility to previous/next grapheme in current item and read it. |
| Shift + H and H | Move to previous/next heading and read information technology. |
| Shift + K and M | Move to previous/side by side link and read it. |
| Shift + D and D | Move to previous/adjacent document landmark (e.thou. <nav>) and read information technology. |
| Shift + ane–6 and 1–vi | Movement to previous/next heading (level 1–6) and read it. |
| Shift + F and F | Move to previous/adjacent form input and focus on it. |
| Shift + T and T | Move to previous/next information tabular array and focus on it. |
| Shift + B and B | Move to previous/next push and read its characterization. |
| Shift + 50 and L | Move to previous/adjacent list and read its first listing detail. |
| Shift + I and I | Move to previous/next listing particular and read it. |
| Enter/Render | (when link/push button or other activatable item is selected) Actuate item. |
| NVDA + Space | (when form is selected) Enter form and then private items can be selected, or leave form if you are already in it. |
| Shift Tab and Tab | (when within form) Move between form inputs. |
| Up cursor and downwardly cursor | (when within form) Change form input values (in the case of things similar select boxes). |
| Spacebar | (when within grade) Select chosen value. |
| Ctrl + Alt + cursor keys | (when a table is selected) Move between table cells. |
Screenreader testing
At present you've gotten used to using a screenreader, we'd like you to use it to do some quick accessibility tests, to get an idea of how screenreaders bargain with expert and bad webpage features:
- Look at good-semantics.html, and note how the headers are constitute by the screenreader and available to use for navigation. Now look at bad-semantics.html, and annotation how the screenreader gets none of this information. Imagine how annoying this would be when trying to navigate a actually long page of text.
- Expect at good-links.html, and note how they make sense when viewed out of context. This is non the case with bad-links.html — they are all just "click here".
- Look at good-form.html, and annotation how the form inputs are described using their labels because we've used
<characterization>elements properly. In bad-form.html, they get an unhelpful characterization along the lines of "blank". - Expect at our punk-bands-complete.html example, and see how the screenreader is able to associate columns and rows of content and read them out all together because we've divers headers properly. In bad-tabular array.html, none of the cells can be associated at all. Annotation that NVDA seems to behave slightly strangely when you've simply got a unmarried tabular array on a page; you could try WebAIM'due south table test page instead.
- Have a look at the WAI-ARIA live regions example we saw earlier, and note how the screen reader will keep reading out the constantly updating section as information technology updates.
User testing
As mentioned above, you tin't rely on automatic tools alone for determining accessibility problems on your site. Information technology is recommended that when yous draw upward your testing plan, you should include some accessibility user groups if at all possible (run across our User Testing department earlier on in the form for some more context). Endeavor to become some screenreader users involved, some keyboard-only users, some non-hearing users, and perhaps other groups as well, equally suits your requirements.
Accessibility testing checklist
The following listing provides a checklist for you to follow to brand sure yous've carried out the recommended accessibility testing for your project:
- Make sure your HTML is as semantically correct as possible. Validating information technology is a good start, as is using an Auditing tool.
- Check that your content makes sense when the CSS is turned off.
- Brand sure your functionality is keyboard attainable. Exam using Tab, Return/Enter, etc.
- Make sure your non-text content has text alternatives. An Auditing tool is proficient for communicable such problems.
- Make sure your site's colour contrast is acceptable, using a suitable checking tool.
- Brand sure hidden content is visible by screenreaders.
- Make sure that functionality is usable without JavaScript wherever possible.
- Utilise ARIA to improve accessibility where appropriate.
- Run your site through an Auditing tool.
- Test it with a screenreader.
- Include an accessibility policy/statement somewhere findable on your site to say what you did.
Finding assistance
At that place are many other issues you'll encounter with accessibility; the most important thing to know really is how to observe answers online. Consult the HTML and CSS commodity'southward Finding help section for some good pointers.
Summary
Hopefully this article has given yous a adept grounding in the primary accessibility problems you might meet, and how to test and overcome them.
In the next article we'll await at feature detection in more detail.
In this module
- Introduction to cantankerous browser testing
- Strategies for carrying out testing
- Handling mutual HTML and CSS problems
- Treatment common JavaScript problems
- Handling common accessibility issues
- Implementing characteristic detection
- Introduction to automated testing
- Setting up your own test automation environment
Reading in a Web Browser Best Practices
Source: https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility
0 Response to "Reading in a Web Browser Best Practices"
Post a Comment