obsługiwana przez technologie wspomagające oraz przez przeglądarki i inne programy użytkownika
- - +wspieranie dostępności przez technologie wspomagające oraz przez przeglądarki i inne programy użytkownika
- Żeby zakwalifikować użycie technologii tworzenia treści internetowych jako obsługiwane przez dostępność, muszą być spełnione oba poniższe warunki: + Żeby zakwalifikować użycie technologii tworzenia treści internetowych jako wspierające dostępność, muszą być spełnione oba poniższe warunki:
-- Technologia treści internetowych musi współpracować z technologiami wspomagającymi. Oznacza to, że sposoby wykorzystywania tej technologii zostały przetestowane pod kątem współdziałania z technologiami wspomagającymi i umożliwiają odczytywanie treści w języku naturalnym + Technologia treści internetowych musi współpracować z technologiami wspomagającymi. Oznacza to, że zastosowania tej technologii zostały przetestowane pod kątem współdziałania z technologiami wspomagającymi i umożliwiają odczytywanie treści w języku naturalnym;
-ORAZ
-Muszą istnieć łatwo osiągalne przez użytkowników narzędzia obsługujące tę technologię. Oznacza to, że co najmniej jedno z czterech poniższych stwierdzeń jest prawdziwe:
-- Taka technologia z założenia jest powszechnie obsługiwana przez programy użytkownika, które również obsługują dostępność (tak jak HTML i CSS); + Taka technologia z założenia jest powszechnie obsługiwana w programach użytkownika, które wspierają również dostępność (tak jak HTML i CSS);
-LUB
- Technologia jest obsługiwana za pomocą szeroko rozpowszechnionej wtyczki, która również obsługuje dostępność; + Technologia jest obsługiwana za pomocą szeroko rozpowszechnionej wtyczki, która również wspiera dostępność;
-LUB
- Treść strony jest dostępna dla zamkniętych środowisk, takich jak środowisko uniwersyteckie lub sieć korporacyjna, gdzie wymagany przez tę technologię program użytkownika i użyty do treści internetowych także obsługuje dostępność; + Treść strony jest dostępna dla zamkniętych środowisk, takich jak środowisko uniwersyteckie lub sieć korporacyjna, gdzie program użytkownika wymagany przez tę technologię i użyty do tworzenia treści internetowych także wspiera dostępność;
-LUB
- Programy użytkownika obsługujące technologię, obsługują dostępność i można je z łatwością pobrać lub zakupić w następujący sposób: + Programy użytkownika obsługujące tę technologię, wspierają dostępność i można je z łatwością pobrać lub zakupić w następujący sposób:
- -- Grupa Robocza WCAG i W3C nie precyzują ani sposobu, ani poziomu obsługi technologii treści internetowych przez technologie wspomagające, aby móc uznać dane technologie internetowe za obsługujące dostępność. Czytaj więcej: Level of Assistive Technology Support Needed for "Accessibility Support" (Poziom wsparcia technologii wspomagających potrzebny do „obsługi dostępności”). + Grupa Robocza WCAG i W3C nie precyzują ani sposobu, ani poziomu wsparcia dla technologii internetowych przez technologie wspomagające, aby można uznać dane technologie internetowe za wspierające dostępność. Zobacz: Level of Assistive Technology Support Needed for "Accessibility Support" (Poziom wsparcia technologii wspomagających potrzebny do „wsparcia dostępności”).
-- Technologie internetowe mogą być wykorzystywane, nawet jeśli nie obsługują dostępności, dopóki nie są uwzględniane w ocenie dostępności, a strona jako całość będzie zgodna z wymogami, w tym z Wymogiem zgodności: 4. Użycie technologii obsługujących dostępność oraz Wymogiem zgodności 5. Brak zakłóceń. + Technologie internetowe mogą być wykorzystywane, nawet jeśli nie wspierają dostępności, dopóki nie są uwzględniane w ocenie dostępności, a strona jako całość będzie zgodna z wymogami, w tym z Wymogiem zgodności: 4. Użycie technologii obsługujących dostępność oraz Wymogiem zgodności 5. Brak zakłóceń.
-- Kiedy technologia używana jest w sposób obsługujący dostępność, nie oznacza to, że wszystkie jej komponenty i ich użycie będą obsługiwały dostępność. Większość technologii, w tym HTML, nie obsługuje dostępności w co najmniej jednym ze swoich komponentów lub sposobie użycia. Strony są zgodne z wytycznymi WCAG tylko wówczas, kiedy użycie technologii obsługującej dostępność, może być uwzględniane jako podstawa oceny zgodności z WCAG. + Gdy technologia używana jest w sposób, który wspiera dostępność, nie oznacza to, że wszystkie jej komponenty i wszystkie sposoby ich użycia wspierają dostępność. Większość technologii, w tym HTML, nie wspiera dostępności w co najmniej jednym ze swoich komponentów lub sposobie użycia. Strony są zgodne z wytycznymi WCAG tylko wówczas, kiedy użycie technologii wspierającej dostępność, może być uwzględniane jako podstawa oceny zgodności z WCAG.
-- Opierając się na technologiach tworzenia treści internetowych, które mają wiele wersji, należy określić, która wersja obsługuje dostępność. + Jeżeli używamy technologii tworzenia treści internetowych, które mają wiele wersji, należy określić, która wersja wspiera dostępność.
-- Jednym ze sposobów dotarcia przez twórców treści internetowych do zastosowań technologii, które obsługują dostępność, jest zapoznanie się z zestawieniami zastosowań udokumentowanych jako obsługujące dostępność (zobacz: Understanding Accessibility-Supported Web Technology Uses - Zrozumieć zastosowania technologii internetowych obsługujących dostępność). Autorzy, firmy, sprzedawcy technologii i inni mogą dokumentować sposoby korzystania z technologii treści internetowych obsługujące dostępność. Jednak dokumentacja wszystkich sposobów i metod zastosowania tych technologii w dokumentacji musiałyby odpowiadać powyższej definicji technologii treści WWW obsługujących dostępność. + Jednym ze sposobów na znalezienie zastosowań technologii, które wspierają dostępność, jest zapoznanie się z zestawieniami, które są udokumentowane jako wspierane pod względem dostępności (zobacz: Understanding Accessibility-Supported Web Technology Uses - Zrozumieć zastosowania technologii internetowych wspierających dostępność). Autorzy, firmy, sprzedawcy technologii i inni mogą dokumentować sposoby korzystania z technologii treści internetowych wspierające dostępność. Ale wszystkie sposoby wykorzystania technologii wskazane w dokumentacji muszą spełniać powyższą definicję technologii internetowych wspierających.
-The intent of this Success Criterion is to minimize the occurrence of content that + requires timed interaction. This enables people with blindness, low vision, cognitive + limitations, or motor impairments to interact with content. This differs from the + Level A Success Criterion in that the only exception is for real-time events. +
+ +Video only, such as sign language, is covered in + Guideline 1.1. + +
+ ++ + A test is designed so that time to complete the test does not affect the scoring + +
+ +Rather than calibrating an on-line test using a time limit, the test is calibrated + based on scores when users have no time limits. +
+ ++ + A game is designed so that users take turns rather than competing in real-time + +
+ +One party can pause the game without invalidating the competitive aspect of it.
+ +The intent of this Success Criterion is to ensure that that content does not "trap" + keyboard focus within subsections of content on a Web page. This is a common problem + when multiple formats are combined within a page and rendered using plug-ins or embedded + applications. +
+ +There may be times when the functionality of the Web page restricts the focus to a + subsection of the content, as long as the user knows how to leave that state and "untrap" + the focus. +
+ + ++ + A calendar widget + +
+ +A calendar widget allows users to add, remove or update items in their calendar using + the keyboard. The controls in the widget are part of the tab order within the Web + page, allowing users to tab through the controls in the widget as well as to any links + or controls that follow. +
+ ++ + A puzzle applet + +
+ +Once a user tabs into an applet, further tabs and other keystrokes are handled by + the applet. Instructions describing the keystroke used to exit the applet are provided + prior to the applet as well as within the applet itself. +
+ ++ + A modal dialog box + +
+ +A Web application brings up a dialog box. At the bottom of the dialog are two buttons, + Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; + tabbing from the last control in the dialog takes focus to the first control in the + dialog. The dialog is dismissed by activating the Cancel button or the OK button. +
+ +The intent of this Success Criterion is to help users understand the purpose of each + link so they can decide whether they want to follow the link. Whenever possible, provide + link text that identifies the purpose of the link without needing additional context. + Assistive technology has the ability to provide users with a list of links that are + on the Web page. Link text that is as meaningful as possible will aid users who want + to choose from this list of links. Meaningful link text also helps those who wish + to tab from link to link. Meaningful links help users choose which links to follow + without requiring complicated strategies to understand the page. +
+ +The text of, or associated with, the link is intended to describe the purpose of the + link. In cases where the link takes one to a document or a web application, the name + of the document or web application would be sufficient to describe the purpose of + the link (which is to take you to the document or web application). Note that it is + not required to use the name of the document or web application; other things may + also describe the purpose of the link. +
+ ++ + Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application + being presented on the page would be sufficient to describe the purpose of the page. + Having the link and the title agree, or be very similar, is good practice and provides + continuity between the link 'clicked on' and the web page that the user lands on. + +
+ +In some situations, authors may want to provide part of the description of the link + in logically related text that provides the context for the link. In this case the + user should be able to identify the purpose of the link without moving focus from + the link. In other words, they can arrive on a link and find out more about it without + losing their place. This can be achieved by putting the description of the link in + the same sentence, paragraph, list item, or table cell as the link, or in the table header cell for a link in a data table, because these are directly associated with the link itself. Alternatively, authors may choose to use an ARIA technique to associate additional + text on the page with the link. +
+ +This context will be most usable if it precedes the link. (For instance, if you must + use ambiguous link text, it is better to put it at the end of the sentence that describes + its destination, rather than putting the ambiguous phrase at the beginning of the + sentence.) If the description follows the link, there can be confusion and difficulty + for screen reader users who are reading through the page in order (top to bottom). + +
+ +It is a best practice for links with the same destination to have consistent text + (and this is a requirement per + Success Criterion 3.2.4 for pages in a set). It is also a best practice for links with different purposes + and destinations to have different link text. +
+ +A best practice for links to conforming alternate versions is to ensure that the link text to the conforming alternate version indicates in link text that the page it leads to represents the more accessible version. This information may also be provided in text - the goal is to ensure that the end user knows what the purpose of the link is.
+ +The Success Criterion includes an exception for links for which the purpose of the + link cannot be determined from the information on the Web page. In this situation, + the person with the disability is not at a disadvantage; there is no additional context + available to understand the link purpose. However, whatever amount of context is available + on the Web page that can be used to interpret the purpose of the link must be made + available in the link text or programmatically associated with the link to satisfy + the Success Criterion. +
+ +There may be situations where the purpose of the link is is supposed to be unknown + or obscured. For instance, a game may have links identified only as door #1, door + #2, and door #3. This link text would be sufficient because the purpose of the links + is to create suspense for all users. +
+ +See also + 2.4.9: Link Purpose (Link Only). +
+ + ++ + A link contains text that gives a description of the information at that URI + +
+ ++ A page contains the sentence "There was much bloodshed during the Medieval period + of history." Where "Medieval period of history" is a link. + +
+ ++ + A link is preceded by a text description of the information at that URI + +
+ ++ A page contains the sentence "Learn more about the Government of Ireland's Commission + on Electronic Voting at Go Vote!" where "Go Vote!" is a link. + +
+ ++ + Both an icon and text are included in the same link + +
+ ++ An icon of a voting machine and the text "Government of Ireland's Commission of Electronic + Voting" are combined to make a single link. The alt text for the icon is null, since + the purpose of the link is already described by the text of the link next to the icon. + +
+ ++ + A list of book titles + +
+ ++ A list of books is available in three formats: HTML, PDF, and mp3 (a recording of + a person reading the book). To avoid hearing the title of each book three times (once + for each format), the first link for each book is the title of the book, the second + link says "PDF" and the third says, "mp3." + +
+ ++ + News article summaries + +
+ ++ A Web page contains a collection of news articles. The main page lists the first few + sentences of each article, followed by a "Read more" link. A screen reader command + to read the current paragraph provides the context to interpret the purpose of the + link. + + +
+ +Allowing the user to choose short or long link text using one of the techniques below:
+ +Providing a supplemental description of the purpose of a link using one of the following + techniques: +
+ ++ Identifying the purpose of a link using link text combined with programmatically determined + link context using one of the following techniques: + +
+ ++ + Providing link text that describes the purpose of a link + + AND Semantically indicating links using one of the following techniques: +
+ + + +The intent of this Success Criterion is to help users understand the purpose of each + link in the content, so they can decide whether they want to follow it. Best practice + is that links with the same destination would have the same descriptions, but links + with different purposes and destinations would have different descriptions (see also + + Success Criterion 3.2.4 which calls for consistency in identifying components that have the same functionality). + Because the purpose of a link can be identified from its link text, links can be understood + when they are out of context, such as when the user agent provides a list of all the + links on a page. +
+ +The text in the link is intended to describe the purpose of the link. In cases where + the link takes one to a document or a web application, the name of the document or + web application would be sufficient to describe the purpose of the link (which is + to take you to the document or web application). Note that it is not required to use + the name of the document or web application; other things may also describe the purpose + of the link. +
+ ++ + Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application + being presented on the page would be sufficient to describe the purpose of the page. + Having the link and the title agree, or be very similar, is good practice and provides + continuity between the link 'clicked on' and the web page that the user lands on. + +
+ +The Success Criterion includes an exception for links for which the purpose of the + link cannot be determined from the information on the Web page. In this situation, + the person with the disability is not at a disadvantage; there is no additional context + available to understand the link purpose. However, whatever amount of context is available + on the Web page that can be used to interpret the purpose of the link must be made + available in the link text to satisfy the Success Criterion. +
+ +The word "mechanism" is used to allow authors to either make all links fully understandable + out of context by default or to provide a way to make them this way. This is done + because for some pages, making the links all unambiguous by themselves makes the pages + easier for some users and harder for others. Providing the ability to make the links + unambiguous (by them selves) or not provides both users with disabilities with the + ability to use the page in the format that best meets their needs. +
+ +For example: A page listing 100 book titles along with links to download the books + in HTML, PDF, DOC, TXT, MP3, or AAC might ordinarily be viewed as the title of the + book as a link with the words "in HTML" after it. then the sentence "Also available + in: " followed by a series of short links with text of "HTML", "PDF", "DOC", "TXT", + "MP3", and "AAC". At Level 3, some users could opt to view the page this way - because + they would find the page harder to understand or slower to use if the full title of + the book were included in each of the links. Others could opt to view the page with + the full title as part of each of the links so that each link was understandable in + itself. Both the former and the latter groups could include people with visual or + cognitive disabilities that used different techniques to browse or that had different + types or severities of disability. +
+ + ++ + Both an icon and text are included in the same link + +
+ +An icon of a voting machine and the text "Government of Ireland's Commission of Electronic + Voting" are combined to make a single link. +
+ ++ + A list of book titles + +
+ +A list of books is available in three formats: HTML, PDF, and mp3 (a recording of + a person reading the book). The title of the book is followed by links to the different + formats. The rendered text for each link is just the format type, but the text associated + with each link includes the title as well as the format; for instance, "Gulliver's + Travels, MP3." +
+ +Allowing the user to choose short or long link text using one of the techniques below:
+ +Providing a supplemental description of the purpose of a link using one of the following + techniques: +
+ +Semantically indicating links using one of the following techniques:
+ + + + +The intent of this Success Criterion is to ensure that users are aware that an error + has occurred and can determine what is wrong. The error message should be as specific + as possible. + In the case of an unsuccessful form submission, re-displaying the form and indicating + the fields in error is insufficient for some users to perceive that an error has occurred. + Screen reader users, for example, will not know there was an error until they encounter + one of the indicators. They may abandon the form altogether before encountering the + error indicator, thinking that the page simply is not functional. Per the definition in WCAG 2.0, an "input error" is information provided by the user + that is not accepted. This includes: +
+ +For example:
+ +If a user enters a value that is too high or too low, and the coding on the page automatically + changes that value to fall within the allowed range, the user's error would still + need to be described to them as required by the success criterion. Such an error description + telling the person of the changed value would meet both this success criterion (Error + Identification) and + Success Criterion 3.3.3 (Error Suggestion). +
+ +The identification and description of an error can be combined with programmatic information + that user agents or assistive technologies can use to identify an error and provide + error information to the user. For example, certain technologies can specify that + the user's input must not fall outside a specific range, or that a form field is required. + Currently, few technologies support this kind of programmatic information, but the + Success Criterion does not require, nor prevent it. + +
+ +It is perfectly acceptable to indicate the error in other ways such as image, color + etc, in addition to the text description. + +
+ +See also + 3.3.3: Error Suggestion. +
+ + ++ + Identifying errors in a form submission + +
+ ++ An airline Web site offers a special promotion on discounted flights. The user is + asked to complete a simple form that asks for personal information such as name, address, + phone number, seating preference and e-mail address. If any of the fields of the form + are either not completed or completed incorrectly, an alert is displayed notifying + the user which field or fields were missing or incorrect. + + +
+ +This Success Criterion does not mean that color or text styles cannot be used to indicate + errors. It simply requires that errors also be identified using text. In this example, + two asterisks are used in addition to color. +
+ ++ + Providing multiple cues + +
+ +The user fails to fill in two fields on the form. In addition to describing the error + and providing a unique character to make it easy to search for the fields, the fields + are highlighted in yellow to make it easier to visually search for them as well. + +
+ +The intent of this Success Criterion is to ensure that user agents can correctly present + content written in multiple languages. This makes it possible for user agents and + assistive technologies to present content according to the presentation and pronunciation + rules for that language. This applies to graphical browsers as well as screen readers, + braille displays, and other voice browsers. +
+ +Both assistive technologies and conventional user agents can render text more accurately + if the language of each passage of text is identified. Screen readers can use the + pronunciation rules of the language of the text. Visual browsers can display characters + and scripts in appropriate ways. This is especially important when switching between + languages that read from left to right and languages that read from right to left, + or when text is rendered in a language that uses a different alphabet. Users with + disabilities who know all the languages used in the Web page will be better able to + understand the content when each passage is rendered appropriately. +
+ +When no other language has been specified for a phrase or passage of text, its human + language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically + determined. +
+ +Individual words or phrases in one language can become part of another language. For + example, "rendezvous" is a French word that has been adopted in English, appears in + English dictionaries, and is properly pronounced by English screen readers. Hence + a passage of English text may contain the word "rendezvous" without specifying that + its human language is French and still satisfy this Success Criterion. Frequently, + when the human language of text appears to be changing for a single word, that word + has become part of the language of the surrounding text. Because this is so common + in some languages, single words should be considered part of the language of the surrounding + text unless it is clear that a change in language was intended. If there is doubt + whether a change in language is intended, consider whether the word would be pronounced + the same (except for accent or intonation) in the language of the immediately surrounding + text. +
+ +Most professions require frequent use of technical terms which may originate from + a foreign language. Such terms are usually not translated to all languages. The universal + nature of technical terms also facilitate communication between professionals. +
+ +Some common examples of technical terms include: Homo sapiens, Alpha Centauri, hertz, + and habeas corpus. +
+ +Identifying changes in language is important for a number of reasons:
+ +This Success Criterion helps:
+ ++ A German phrase in an English sentence. +
+In the sentence, "He maintained that the DDR (German Democratic Republic) was just + a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German. Depending on the markup language, English may either be marked + as the language for the entire document except where specified, or marked at the paragraph + level. When a screen reader encounters the German phrase, it changes pronunciation + rules from English to German to pronounce the word correctly. +
++ Alternative language links +
+An HTML Web page includes links to versions of the page in other languages (e.g.,
+ Deutsch, Français, Nederlands, Catalan, etc.). The text of each link is the name of the language, in that language. The language of each link is indicated via a lang attribute.
+
+ "Podcast" used in a French sentence. +
+Because "podcast" is part of the vernacular of the immediately surrounding text in + the following excerpt, "À l'occasion de l'exposition "Energie éternelle. 1500 ans d'art indien", le Palais des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce podcast au format M4A et MP3", no indication of language change is required. +
++ The intent of this Success Criterion is to ensure that content developers provide + information in the Web page that user agents need to present text and other linguistic + content correctly. Both assistive technologies and conventional user agents can render + text more accurately when the language of the Web page is identified. Screen readers + can load the correct pronunciation rules. Visual browsers can display characters and + scripts correctly. Media players can show captions correctly. As a result, users with + disabilities will be better able to understand the content. + +
+ +The default human language of the Web page is the default text-processing language + as discussed in + Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is + the language which is used most. (If several languages are used equally, the first + language used should be chosen as the default human language.) + +
+ ++ For multilingual sites targeting Conformance Level A, the Working Group strongly encourages + developers to follow Success Criterion 3.1.2 as well even though that is a Level AA + Success Criterion. + + +
+ +This Success Criterion helps:
+ ++ + Example 1. A Web page with content in two languages + +
+ +A Web page produced in Germany and written in HTML includes content in both German + and English, but most of the content is in German. The default human language is identified + as German (de) by the lang attribute on the html element. + +
+ +The intent of this Success Criterion is to ensure that + all content is operable from the keyboard. This is the same as Success Criterion 2.1.1, + except that no exceptions are allowed. This does not mean that content where the underlying + function requires input that depends on the path of the user's movement and not just + the endpoints (excluded from the requirements of 2.1.1) must be made keyboard accessible. + Rather, it means that content that uses path-dependent input cannot conform to this + Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA. +
+ +No additional techniques exist for this Success Criterion. Follow + techniques for Success Criterion 2.1.1. If that is not possible because there is a requirement for path-dependent input, + then it is not possible to meet this Level AAA Success Criterion. +
+ +The intent of this Success Criterion is to ensure that when users navigate sequentially + through content, they encounter information in an order that is consistent with the + meaning of the content and can be operated from the keyboard. This reduces confusion + by letting users form a consistent mental model of the content. There may be different + orders that reflect logical relationships in the content. For example, moving through + components in a table one row at a time or one column at a time both reflect the logical + relationships in the content. Either order may satisfy this Success Criterion. +
+ +The way that sequential navigation order is determined in Web content is defined by + the technology of the content. For example, simple HTML defines sequential navigation + via the notion of tabbing order. Dynamic HTML may modify the navigation sequence using + scripting along with the addition of a tabindex attribute to allow focus to additional + elements. If no scripting or tabindex attributes are used, the navigation order is + the order that components appear in the content stream. (See HTML 4.01 Specification, + section 17.11, "Giving focus to an element"). +
+ +An example of keyboard navigation that is not the sequential navigation addressed + by this Success Criterion is using arrow key navigation to traverse a tree component. + The user can use the up and down arrow keys to move from tree node to tree node. Pressing + the right arrow key may expand a node, then using the down arrow key, will move into + the newly expanded nodes. This navigation sequence follows the expected sequence for + a tree control - as additional items get expanded or collapsed, they are added or + removed from the navigation sequence. +
+ +The focus order may not be identical to the programmatically determined reading order + (see Success Criterion 1.3.2) as long as the user can still understand and operate + the Web page. Since there may be several possible logical reading orders for the content, + the focus order may match any of them. However, when the order of a particular presentation + differs from the programmatically determined reading order, users of one of these + presentations may find it difficult to understand or operate the Web page. Authors + should carefully consider all these users as they design their Web pages. +
+ +For example, a screen reader user interacts with the programmatically determined reading + order, while a sighted keyboard user interacts with the visual presentation of the + Web page. Care should be taken so that the focus order makes sense to both of these + sets of users and does not appear to either of them to jump around randomly. +
+ +For clarity:
+ +These techniques benefit keyboard users who navigate documents sequentially and expect + the focus order to be consistent with the sequential reading order. +
+ +An HTML Web page is created with the left hand navigation occurring in the HTML after + the main body content, and styled with CSS to appear on the left hand side of the + page. This is done to allow focus to move to the main body content first without requiring + tabIndex attributes or JavaScript. +
+ +While this example passes the Success Criterion, it is not necessarily true that all + CSS positioning would. More complex positioning examples may or may not preserve meaning + and operability +
+ +The following example + fails to meet the Success Criterion: +
+ +A company's Web site includes a form that collects marketing data and allows users + to subscribe to several newsletters published by the company. The section of the form + for collecting marketing data includes fields such as name, street address, city, + state or province, and postal code. Another section of the form includes several checkboxes + so that users can indicate newsletters they want to receive. However, the tab order + for the form skips between fields in different sections of the form, so that focus + moves from the name field to a checkbox, then to the street address, then to another + checkbox. +
+ +Giving focus to elements in an order that follows sequences and relationships within + the content using one of the following techniques: +
+ +Changing a Web page dynamically using one of the following techniques:
+ + + +Individuals who use screen reading software can find it hard to hear the speech output + if there is other audio playing at the same time. This difficulty is exacerbated when + the screen reader's speech output is software based (as most are today) and is controlled + via the same volume control as the sound. Therefore, it is important that the user + be able to turn off the background sound. Note: Having control of the volume includes + being able to reduce its volume to zero. +
+ +Playing audio automatically when landing on a page may affect a screen reader user's + ability to find the mechanism to stop it because they navigate by listening and automatically + started sounds might interfere with that navigation. Therefore, we discourage the + practice of automatically starting sounds (especially if they last more than 3 seconds), + and encourage that the sound be + started by an action initiated by the user after they reach the page, rather than requiring + that the sound be + stopped by an action of the user after they land on the page. +
+ +See also + 1.4.2: Low or No Background Audio. +
+ + +