To Do This Too on the Footer of the Current Page and Execute Step 6 Again

Treatment common accessibility bug

Previous
Overview: Cross browser testing
Next

Next we turn our attention to accessibility, providing information on common problems, how to practise uncomplicated testing, and how to make use of auditing/automation tools for finding accessibility bug.

What is accessibility?

When we say accessibility in the context of web technology, nearly people immediately think of making sure websites/apps are usable by people with disabilities, for instance:

Visually impaired people using screen readers or magnification/zoom to access text
People with motor function impairments using the keyboard (or other non-mouse features) to actuate website functionality.
People with hearing impairments relying on captions/subtitles or other text alternatives for audio/video content.

However, it is wrong to say that accessibility is merely nigh disabilities. Really, the aim of accessibility is to make your websites/apps usable by every bit many people in equally many contexts every bit possible, not just those users using loftier-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 tedious processors.

In a mode, this whole module is about accessibility — cross browser testing makes sure that your sites can exist used by as many people every bit possible. What is accessibility? defines accessibility more completely and thoroughly than this article does.

That said, this commodity will comprehend cross browser and testing issues surrounding people with disabilities, and how they employ the Web. Nosotros've already talked about other spheres such as responsive design and operation in other places in the module.

Annotation: Like many things in spider web development, accessibility isn't about 100% success or non; 100% accessibility is pretty much impossible to achieve for all content, specially as sites get more complex. Instead, information technology is more about making a reasonable effort to make equally much of your content accessible to as many people as possible via defensive coding and sticking to best practices.

Mutual accessibility issues

In this section we'll particular some of the main bug that ascend around web accessibility, connected with specific technologies, along with best practices to follow, and some quick tests yous tin can do to see if your sites are going in the right direction.

Note: Accessibility is morally the right thing to practice, and good for business concern (numbers of disabled users, users on mobile devices, etc. present pregnant market segments), just it 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 information.

HTML

Semantic HTML (where the elements are used for their correct purpose) is attainable correct out of the box — such content is readable by sighted viewers (provided you don't practice anything light-headed like make the text way also small or hide it using CSS), just will also be usable by assistive technologies like screen readers (apps that literally read out a spider web page to their user), and confer other advantages too.

Semantic structure

The most important quick win in semantic HTML is to utilize a structure of headings and paragraphs for your content; this is because screen reader users tend to use the headings of a document as signposts to discover the content they need more quickly. If your content has no headings, all they will go is a huge wall of text with no signposts to find anything. Examples of bad and good HTML:

                                                                                    <font                      size                                              =                        "7"                                            >                    My heading                                              </font                      >                                                                                      <br                      >                                                                                      <br                      >                                        This is the first section of my document.                                                                  <br                      >                                                                                      <br                      >                                        I'll add some other paragraph hither too.                                                                  <br                      >                                                                                      <br                      >                                                                                      <font                      size                                              =                        "v"                                            >                    My subheading                                              </font                      >                                                                                      <br                      >                                                                                      <br                      >                                        This is the kickoff subsection of my document. I'd love people to be able to observe this content!                                                                  <br                      >                                                                                      <br                      >                                                                                      <font                      size                                              =                        "5"                                            >                    My second subheading                                              </font                      >                                                                                      <br                      >                                                                                      <br                      >                                        This is the second subsection of my content. I call up it is more interesting than the last one.

                                                                                    <h1                      >                    My heading                                              </h1                      >                                                                                      <p                      >                    This is the first section of my document.                                              </p                      >                                                                                      <p                      >                    I'll add another paragraph here likewise.                                              </p                      >                                                                                      <h2                      >                    My subheading                                              </h2                      >                                                                                      <p                      >                    This is the first subsection of my document. I'd love people to exist able to find this content!                                              </p                      >                                                                                      <h2                      >                    My 2nd subheading                                              </h2                      >                                                                                      <p                      >                    This is the 2d subsection of my content. I think it is more interesting than the last one.                                              </p                      >

In addition, your content should brand logical sense in its source order — you can e'er place information technology where you desire using CSS afterward, but you should get the source order right to start with.

Every bit a test, yous tin turn off a site's CSS and see how understandable information technology is without it. You could do this manually by merely removing the CSS from your lawmaking, just the easiest way is to use browser features, for case:

Firefox: Select View > Page Fashion > No Fashion from the main menu.
Safari: Select Develop > Disable Styles from the main menu (to enable the Develop menu, choose Safari > Preferences > Advanced > Show Develop menu in menu bar).
Chrome: Install the Spider web Developer Toolbar extension, then restart the browser. Click the gear icon that volition announced, so select CSS > Disable All Styles.
Edge: Select View > Style > No Style from the master menu.

Using native keyboard accessibility

Certain HTML features can be selected using just the keyboard — this is default behavior, bachelor since the early days of the web. The elements that have this capability are the common ones that allow user to interact with spider web pages, namely links, <push button>s, and course elements like <input>.

You can try this out using our native-keyboard-accessibility.html example (come across the source lawmaking) — open this in a new tab, and endeavour pressing the tab key; subsequently a few presses, yous should see the tab focus start to move through the unlike focusable elements; the focused elements are given a highlighted default style in every browser (it differs slightly betwixt different browsers) so that you tin tell what element is focused.

You can then press Enter/Return to follow a focused link or press a button (nosotros've included some JavaScript to make the buttons alert a message), or start typing to enter text in a text input (other form elements accept different controls, for instance the <select> element can take its options displayed and cycled between using the up and down pointer keys).

Note that different browsers may accept different keyboard control options available. Virtually modern browsers follow the tab pattern described higher up (y'all can also practise Shift + Tab to move backwards through the focusable elements), simply some browsers have their own idiosyncrasies:

Firefox for the Mac doesn't do tabbing past default. To plough it on, yous have to get to Preferences > Advanced > General, then uncheck "Always apply the cursor keys to navigate within pages". Next, you have to open your Mac's Organization Preferences app, and so go to Keyboard > Shortcuts, then select the All Controls radio button.
Safari doesn't allow y'all to tab through links by default; to enable this, y'all demand to open Safari'southward Preferences, become to Advanced, and cheque the Press Tab to highlight each detail on a webpage checkbox.

Warning: Yous should perform this kind of test/review on whatsoever new page you write — make sure that functionality can be accessed by the keyboard, and that the tab order provides a sensible navigation path through the certificate.

This example highlights the importance of using the correct semantic element for the correct job. Information technology is possible to mode any element to look similar a link or button with CSS, and to behave similar a link or push with JavaScript, but they won't actually be links or buttons, and you'll lose a lot of the accessibility these elements requite you for gratis. So don't do it if you can avoid it.

Some other tip — as shown in our case, you lot can command how your focusable elements look when focused, using the :focus pseudo-class. It is a proficient idea to double upwardly focus and hover styles, and then your users get that visual clue 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, push button:focus, select:focus                    {                    font-weight                    :                    bold;                    }

Note: If y'all do decide to remove the default focus styling using CSS, brand certain you replace it with something else that fits in with your blueprint better — it is a very valuable accessibility tool, and should non be removed.

Building in keyboard accessibility

Sometimes it is not possible to avert losing keyboard accessibility. You lot might have inherited a site where the semantics are not very good (peradventure y'all've ended upward with a horrible CMS that generates buttons made with <div>s), or you are using a complex control that does not have keyboard accessibility built in, like the HTML5 <video> chemical element (amazingly, Opera is the merely browser that allows yous to tab through the <video> chemical element's default browser controls). Y'all have a few options here:

Create custom controls using <push> elements (which nosotros can tab to by default!) and JavaScript to wire up their functionality. See Creating a cross-browser video role player for some good examples of this.
Create keyboard shortcuts via JavaScript, and then functionality is activated when you printing certain keys on the keyboard. See Desktop mouse and keyboard controls for some game-related examples that tin can be adapted for any purpose.

Use some interesting tactics to fake button beliefs. Have for case our false-div-buttons.html example (see source code). Here we've given our faux <div> buttons the ability to exist focused (including via tab) by giving each ane the attribute tabindex="0" (see WebAIM's tabindex article for more really useful details). This allows u.s.a. to tab to the buttons, but not to activate them via the Enter/Render key. To practice that, we had to add together the post-obit bit of JavaScript trickery:

                      document.                        onkeydown                        =                        function                        (                        east                        )                        {                        if                        (e.keyCode                        ===                        13                        )                        {                        // The Enter/Return key                        document.activeElement.                        onclick                        (e)                        ;                        }                        }                        ;

Here nosotros add a listener to the document object to discover when a button has been pressed on the keyboard. We check what button was pressed via the event object'southward keyCode property; if it is the keycode that matches Render/Enter, nosotros run the function stored in the push's onclick handler using document.activeElement.onclick(). activeElement gives united states of america the element that is currently focused on the page.

Note: This technique will simply work if you ready your original event handlers via event handler properties (eastward.k. onclick). addEventListener won't work. This is a lot of extra hassle to build the functionality dorsum in. And there'due south leap to be other problems with information technology. Better to just use the right element for the right chore in the first identify.

Text alternatives

Text alternatives are very important for accessibility — if a person has a visual or hearing damage that stops them being able to see or hear some content, then this is a problem. The simplest text alternative available is the apprehensive 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 exist picked upwards by a screenreader and read out to the user.

Missing alt text can be tested for in a number of ways, for case using accessibility Auditing tools.

Alt text is slightly more complex for video and audio content. In that location is a manner to ascertain text tracks (e.g. subtitles) and display them when video is being played, in the form of the <runway> element, and the WebVTT format (see Adding captions and subtitles to HTML5 video for a detailed tutorial). Browser compatibility for these features is fairly adept, merely if y'all want to provide text alternatives for sound or back up older browsers, a simple text transcript presented somewhere on the page or on a separate page might be a good idea.

Element relationships and context

There are certain features and best practices in HTML designed to provide context and relationships between elements where none otherwise exists. The three almost common examples are links, class labels, and data tables.

The cardinal to accessible link text is that people using screen readers will frequently use a common feature whereby they pull upwardly a list of all the links on the page. In this case, the link text needs to brand sense out of context. For example, a listing of links labeled "click hither", "click me", etc. is really bad for accessibility. Information technology is better for link text to brand sense in context and out of context.

Adjacent on our list, the course <label> element is one of the central features that allows us to make forms accessible. The problem with forms is that you lot need labels to say what data should exist entered into each form input. Each label needs to be included within a <label> to link it unambiguously to its partner form input (each <label> for attribute value needs to match the form element id value), and information technology volition make sense even if the source lodge is not completely logical (which to be fair it should exist).

Finally, a quick discussion about data tables. A basic data table tin be written with very simple markup (see bad-tabular array.html alive, and source), simply this has bug — there is no way for a screen reader user to associate rows or columns together equally groupings of information — to exercise this y'all need to know what the header rows are, and if they are heading upwardly rows, columns, etc. This can only be done visually for such a table.

If you lot instead look at our punk-bands-complete.html example (live, source), you can meet a few accessibility aids at piece of work here, such as table headers (<th> and scope attributes), <explanation> element, etc.

CSS

CSS tends to provide a lot fewer fundamental accessibility features than HTML, but it can still practice just as much harm to accessibility if used incorrectly. We have already mentioned a couple of accessibility tips involving CSS:

Use the right semantic elements to mark up dissimilar content in HTML; if you lot want to create a different visual result, use CSS — don't abuse an HTML element to become the await you want. For case, if yous want bigger text, employ font-size, not an <h1> element.
Brand certain your source lodge makes sense without CSS; yous can always employ CSS to style the page whatever manner y'all want after.
You lot should brand certain interactive elements like buttons and links take advisable focus/hover/active states set, to give the user visual clues as to their part. If you remove the defaults for stylistic reasons, brand sure you lot include some replacement styles.

There are a few other considerations you should take into account.

Color and color contrast

When choosing a colour scheme for your website, yous should make certain that the text (foreground) colour contrasts well with the background color. Your design might expect absurd, but it is no good if people with visual impairments like colour 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 colour alone for signposts/information, as this will be no skilful for those who tin't run across the color. Instead of marking required form fields in cerise, for example, marking them with an asterisk and in scarlet.

Note: A high contrast ratio will also allow anyone using a smartphone or tablet with a glossy screen to better read pages when in a bright environment, such as sunlight.

Hiding content

In that location are many instances where a visual design will require that non all content is shown at in one case. For example, in our Tabbed info box example (encounter source code) we have three panels of information, but we are positioning them on top of one some other and providing tabs that tin can be clicked to prove each one (it is too keyboard accessible — y'all can alternatively use Tab and Enter/Return to select them).

Screen reader users don't care nigh any of this — they are happy with the content every bit long as the source order makes sense, and they can go to it all. Absolute positioning (every bit used in this instance) is mostly seen equally i of the all-time mechanisms of hiding content for visual effect, because it doesn't terminate screen readers from getting to it.

On the other hand, y'all shouldn't apply visibility :hidden or display :none, considering they practice hibernate content from screenreaders. Unless of course, there is a skillful reason why you want this content to be hidden 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. Nosotros've already hinted at some accessibility bug related to JavaScript, mainly in the area of semantic HTML — you lot should ever utilise appropriate semantic HTML to implement functionality wherever it is available, for instance use links and buttons as advisable. Don't use <div> elements with JavaScript code to fake functionality if at all possible — it is error decumbent, and more work than using the complimentary functionality HTML gives you.

Elementary functionality

By and large elementary functionality should work with merely the HTML in place — JavaScript should only be used to enhance functionality, not build it in entirely. Practiced uses of JavaScript include:

Providing customer-side form validation, which alerts users to issues with their form entries quickly, without having to wait for the server to bank check the information. If information technology isn't bachelor, the course will withal work, just validation might be slower.
Providing custom controls for HTML5 <video>s that are accessible to keyboard-only users (as we said earlier, the default browser controls aren't keyboard-attainable in most browsers).

Note: WebAIM's Accessible JavaScript provides some useful further details almost considerations for accessible JavaScript.

More circuitous JavaScript implementations can create problems with accessibility — you need to do what you can. For example, it would exist unreasonable to expect you to brand a complex 3D game written using WebGL 100% accessible to a blind person, but you could implement keyboard controls then it is usable past non-mouse users, and make the color scheme contrasting enough to be usable past those with color deficiencies.

Complex functionality

One of the main areas problematic for accessibility is complex apps that involve complicated form controls (such every bit appointment pickers) and dynamic content that is updated oftentimes and incrementally.

Non-native complicated form controls are problematic considering they tend to involve a lot of nested <div>south, and the browser does not know what to do with them by default. If you are inventing them yourself, you need to make sure that they are keyboard attainable; if you are using some kind of third-party framework, carefully review the options bachelor to run into how attainable they are before diving in. Bootstrap looks to exist fairly good for accessibility, for instance, although Making Bootstrap a Little More Accessible past Rhiana Heath explores some of its issues (mainly related to color dissimilarity), and looks at some solutions.

Regularly updated dynamic content tin be a problem because screenreader users might miss it, especially if it updates unexpectedly. If y'all have a unmarried-folio app with a chief content panel that is regularly updated using XMLHttpRequest or Fetch, a screenreader user might miss those updates.

WAI-ARIA

Practice you lot need to apply such complex functionality, or will manifestly old semantic HTML do instead? If yous do need complexity, you should consider using WAI-ARIA (Accessible Rich Internet Applications), a specification that provides semantics (in the form of new HTML attributes) for items such as complex form controls and updating panels that can be understood by most browsers and screen readers.

To deal with complex form widgets, y'all need to use ARIA attributes like roles to state what role different elements have in a widget (for example, are they a tab, or a tab panel?), aria-disabled to say whether a control is disabled or not, etc.

To deal with regularly updating regions of content, you tin utilise the aria-live attribute, which identifies an updating region. Its value indicates how urgently the screen reader should read it out:

off: The default. Updates should not be announced.
polite: Updates should be announced only if the user is idle.
assertive: Updates should exist announced to the user as soon as possible.
rude: Updates should be announced direct away, even if this interrupts the user.

Hither's an example:

                                                                                    <p                      >                                                                                      <span                      id                                              =                        "LiveRegion1"                                            aria-live                                              =                        "polite"                                            aria-atomic                                              =                        "simulated"                                            >                                                                                      </bridge                      >                                                                                      </p                      >

You can come across an example in activeness at Freedom Scientific's ARIA (Accessible Rich Internet Applications) Live Regions case — the highlighted paragraph should update its content every 10 seconds, and a screenreader should read this out to the user. ARIA Live Regions - Diminutive provides another useful case.

We don't have space to comprehend WAI-ARIA in detail here, you can acquire a lot more about it at WAI-ARIA basics.

Now we've covered accessibility considerations for different web technologies, including a few testing techniques (like keyboard navigation and color contrast checkers), let's have a look at other tools you can brand use of when doing accessibility testing.

Auditing tools

There are a number of auditing tools available that you can feed your web pages into. They will look over them and return a listing of accessibility bug nowadays on the page. Examples include:

Wave: A rather nice online accessibility testing tool that accepts a web accost and returns a useful annotated view of that page with accessibility bug 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 impact, 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.

Let's look at an instance, using Moving ridge.

Go to the Wave homepage.
Enter the URL of our bad-semantics.html case into the text input box almost 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 answer with a clarification of the accessibility problems. Click the icons displayed to see more than data about each of the issues identified by Moving ridge'southward evaluation.

Annotation: Such tools aren't good enough to solve all your accessibility problems on their own. You'll need a combination of these, cognition and feel, user testing, etc. to become a full picture.

Automation tools

Deque's aXe tool goes a scrap further than the auditing tools we mentioned in a higher place. Like the others, it checks pages and returns accessibility errors. Its about 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 instance, we installed the Firefox version, then used information technology to audit our bad-tabular array.html case. Nosotros got the following results:

aXe is as well installable using npm, and can be integrated with task runners like Grunt and Gulp, automation frameworks like Selenium and Cucumber, unit testing frameworks similar Jasmine, and more too (once again, see the master aXe folio for details).

Screenreaders

Information technology is definitely worth testing with a screenreader to get 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 gratuitous products, like NVDA (Windows), ChromeVox (Chrome, Windows, and macOS), and Orca (Linux).
Some are built into the operating arrangement, like VoiceOver (macOS and iOS), ChromeVox (on Chromebooks), and TalkBack (Android).

Generally, screen readers are separate apps that run on the host operating arrangement and tin read non only web pages, only text in other apps also. This is not always the case (ChromeVox is a browser extension), but normally. Screenreaders tend to act in slightly different ways and have dissimilar controls, so you'll have to consult the documentation for your called screen reader to get all of the details — saying that, they all work in basically the same sort of way.

Allow's go through some tests with a couple of different screenreaders to requite you a general thought of how they piece of work and how to test with them.

VoiceOver

VoiceOver (VO) comes free with your Mac/iPhone/iPad, then it'southward useful for testing on desktop/mobile if you apply Apple tree products. We'll exist testing it on Mac Bone X on a MacBook Pro.

To turn information technology on, press Cmd + F5. If y'all've non used VO before, you will be given a welcome screen where you lot tin can choose to kickoff VO or not, and run through a rather useful tutorial to learn how to use it. To turn information technology off over again, printing Cmd + F5 once again.

Notation: Y'all should become through the tutorial at to the lowest degree once — it is a really useful way to learn VO.

When VO is on, the brandish will look more often than not the same, just you'll see a black box at the bottom left of the screen that contains data on what VO currently has selected. The electric current choice will besides be highlighted, with a blackness edge — this highlight is known as the VO cursor.

To use VO, you volition make a lot of use of the "VO modifier" — this is a key or fundamental combination that y'all need to printing in addition to the bodily VO keyboard shortcuts to go them to work. Using a modifier similar this is common with screenreaders, to enable them to keep their commands from clashing with other commands. In the case of VO, the modifier can either be CapsLock, or Ctrl + Option.

VO has many keyboard commands, and we won't list them all here. The bones ones you lot'll need for web page testing are in the following tabular array. In the keyboard shortcuts, "VO" means "the VoiceOver modifier".

This seems like a lot of commands, but it isn't so bad when you get used to it, and VO regularly gives y'all reminders of what commands to use in certain places. Have a play with VO at present; you can then go on to play with some of our examples in the Screenreader testing section.

NVDA

NVDA is Windows-only, and you lot'll need to install it.

Download it from nvaccess.org. You can cull whether to make a donation or download information technology for free; you'll also demand to give them your e-mail address before you can download it.
One time 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 use the keyboard shortcut Ctrl + Alt + Northward. Y'all'll see the NVDA welcome dialog when you start it. Hither yous can choose from a couple of options, then press the OK button to go going.

NVDA will now be active on your reckoner.

To use NVDA, you volition make a lot of use of the "NVDA modifier" — this is a fundamental that y'all need to press in addition to the actual NVDA keyboard shortcuts to get them to work. Using a modifier like this is mutual with screenreaders, to enable them to keep their commands from clashing with other commands. In the case of NVDA, the modifier can either be Insert (the default), or CapsLock (can exist chosen by checking the first 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 you are scrolling through headings, lists, etc., items you are selected on volition more often than not be highlighted with a subtle outline, but this is non always the case for all things. If yous get completely lost, you can printing Ctrl + F5 to refresh the electric current page and begin from the acme again.

NVDA has many keyboard commands, and we won't list them all here. The basic ones you'll need for web page testing are in the following table. In the keyboard shortcuts, "NVDA" means "the NVDA modifier".

Screenreader testing

At present yous've gotten used to using a screenreader, we'd like you to utilise information technology to do some quick accessibility tests, to get an idea of how screenreaders deal with proficient and bad webpage features:

Look at adept-semantics.html, and notation how the headers are found by the screenreader and available to utilise for navigation. Now await at bad-semantics.html, and note how the screenreader gets none of this data. Imagine how annoying this would be when trying to navigate a really long folio of text.
Look at good-links.html, and note how they brand sense when viewed out of context. This is non the case with bad-links.html — they are all just "click here".
Look at expert-class.html, and note how the form inputs are described using their labels considering we've used <label> elements properly. In bad-form.html, they become an unhelpful characterization forth the lines of "bare".
Look at our punk-bands-consummate.html example, and see how the screenreader is able to associate columns and rows of content and read them out all together considering nosotros've defined headers properly. In bad-table.html, none of the cells can exist associated at all. Annotation that NVDA seems to behave slightly strangely when you've only got a unmarried table on a page; you could try WebAIM's tabular array test page instead.
Have a look at the WAI-ARIA live regions example we saw earlier, and note how the screen reader volition keep reading out the constantly updating section every bit information technology updates.

User testing

As mentioned to a higher place, you lot can't rely on automated tools alone for determining accessibility problems on your site. It is recommended that when you describe up your testing plan, you should include some accessibility user groups if at all possible (run across our User Testing section before on in the course for some more context). Effort to get some screenreader users involved, some keyboard-merely users, some non-hearing users, and possibly other groups likewise, as suits your requirements.

Accessibility testing checklist

The post-obit listing provides a checklist for you lot to follow to brand certain yous've carried out the recommended accessibility testing for your project:

Make sure your HTML is every bit semantically right as possible. Validating it is a good get-go, as is using an Auditing tool.
Check that your content makes sense when the CSS is turned off.
Make sure your functionality is keyboard accessible. Test using Tab, Render/Enter, etc.
Make sure your non-text content has text alternatives. An Auditing tool is good for communicable such problems.
Brand sure your site's color contrast is adequate, using a suitable checking tool.
Brand sure subconscious content is visible by screenreaders.
Brand sure that functionality is usable without JavaScript wherever possible.
Use ARIA to improve accessibility where appropriate.
Run your site through an Auditing tool.
Test it with a screenreader.
Include an accessibility policy/argument somewhere findable on your site to say what y'all did.

Finding aid

There are many other issues you'll encounter with accessibility; the almost of import thing to know really is how to observe answers online. Consult the HTML and CSS article's Finding help section for some good pointers.

Summary

Hopefully this commodity has given yous a good grounding in the principal accessibility bug you might see, and how to exam and overcome them.

In the next article we'll look at feature detection in more particular.

Previous
Overview: Cross browser testing
Next

In this module

plowmanbeirt1952.blogspot.com

Source: https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility