text:
This document is also available in these non-normative formats:
single HTML, plain
gzip PostScript,
Black/white gzip PostScript,
gzip PDF, gzip
tar file of HTML, and
zip archive of HTML. Note: Some user agents unzip the
gzipped files on the fly without changing the file suffix. If you encounter
problems reading the gzipped files, remove the
.gz suffix and try
Copyright © 1999 - 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document provides techniques for satisfying the checkpoints defined in "User Agent Accessibility Guidelines 1.0" [UAAG10]. These techniques address key aspects of the accessibility of user interfaces, content rendering, application programming interfaces (APIs), and languages such as the Hypertext Markup Language (HTML), Cascading Style Sheets (CSS) and the Synchronized Multimedia Integration Language (SMIL).
The techniques listed in this document are not required for conformance to the Guidelines. These techniques are not necessarily the only way of satisfying the checkpoint, nor are they a definitive set of requirements for satisfying a checkpoint.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is the 21 August 2002 Working Draft of "Techniques for User Agent Accessibility Guidelines 1.0". It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or participants in the User Agent Accessibility Guidelines Working Group (UAWG).
While User Agent Accessibility Guidelines 1.0 strives to be a stable document (as a W3C Recommendation), the current document is expected to evolve as technologies change and content developers discover more effective techniques for designing accessible Web sites and pages.
A list of changes to this document is available.
The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, there are no disclosures.
Please send comments about this document, including suggestions for additional techniques, to the public mailing list firstname.lastname@example.com; public archives are available.
This document is part of a series of accessibility documents published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). WAI Accessibility Guidelines are produced as part of the WAI Technical Activity. The goals of the User Agent Accessibility Guidelines Working Group are described in the charter.
A list of current W3C Recommendations and other technical documents can be found at the W3C Web site.
This document discusses implementation details that should be helpful to understanding how to satisfy the requirements of "User Agent Accessibility Guidelines 1.0" [UAAG10]. This document includes:
In an effort to improve the readability of this document, some information from User Agent Accessibility Guidelines 1.0 has been copied here:
In an effort to reduce the size of the current document, some information that is in User Agent Accessibility Guidelines 1.0 has not been copied here:
The current document includes a list of references resources that is not part of User Agent Accessibility Guidelines 1.0.
"Techniques for User Agent Accessibility Guidelines 1.0" and the "User Agent Accessibility Guidelines 1.0" are part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). These documents explain the responsibilities of user agent developers in making the Web more accessible to users with disabilities. The series also includes the "Web Content Accessibility Guidelines 1.0" [WCAG10] (and techniques [WCAG10-TECHS]), which explain the responsibilities of authors, and the "Authoring Tool Accessibility Guidelines 1.0" [ATAG10] (and techniques [ATAG10-TECHS]), which explain the responsibilities of authoring tool developers.
This section lists each checkpoint of "User Agent Accessibility Guidelines 1.0" [UAAG10] along with some possible techniques for satisfying it. Each checkpoint definition includes a link to the checkpoint definition in "User Agent Accessibility Guidelines 1.0". Each checkpoint definition is followed by one or more of the following:
Note: Most of the techniques in this document are designed for graphical browsers and multimedia players running on desktop computers. However, some of them also make sense for assistive technologies and other user agents. In particular, techniques about communication between user agents will benefit assistive technologies. Refer, for example, to the appendix on loading assistive technologies for access to the document object model.
Each checkpoint in this document is assigned a priority that indicates its importance for users with disabilities.
Note: This information about checkpoint priorities is included for convenience only. For detailed information about conformance to "User Agent Accessibility Guidelines 1.0" [UAAG10], please refer to that document.
Note: For example, ensure that the user can interact with enabled elements, select content, navigate viewports, configure the user agent, access documentation, install the user agent, operate user interface controls, etc., all entirely through keyboard input.
User agents generally support at least three types of keyboard operation:
User agents should support direct or sequential keyboard operation for all functionalities. Furthermore, the user agent should satisfy this checkpoint by offering a combination of keyboard-operable user interface controls (e.g., keyboard operable print menus and settings) and direct keyboard shortcuts (e.g., to print the current page).
It is also possible to claim conformance to User Agent Accessibility Guidelines 1.0 [UAAG10] for full support through pointing device input and/or voice input. See the section on Input modality labels in UAAG 1.0.
Note: Refer to the checkpoints of guideline 9 for more information about focus requirements.
DocumentEvent.createEvent, which takes an event type as parameter,
onkeydown, and
DOMActivate. These events are specified independent of a
particular input device type.
mousemove and
IHTMLDocument4::fireEvent method on that node.
Note: For example, if the user is alerted of an event by an audio cue, a visually-rendered text equivalent in the status bar could satisfy this checkpoint. Per checkpoint 6.5, a text equivalent for each such message must be available through an API. See also checkpoint 6.6 for requirements for programmatic notification of changes to the user interface.
alt" attribute in HTML, the rendering order of
OBJECT elements in HTML, test attributes in SMIL, and the
cascade in CSS2).
Note: If a conforming user agent does not render a content type, it should allow the user to choose a way to handle that content (e.g., by launching another application, by saving it to disk, etc.).
Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.
Note: For instance, an HTML user agent might allow users to
query each element for access to conditional content supplied for the
alt", "
title", and "
attributes. Or, the user agent might allow configuration so that the value of
the "
alt" attribute is rendered in place of all
elements (while other conditional content might be made available through
another mechanism).
title, and
alt attributes are to be read aloud.
IMG elements:
Note: If the user agent satisfies this checkpoint by
pausing automatically, it may be necessary to pause more than once when there
are multiple opportunities for time-sensitive user interaction. When pausing,
pause synchronized content as well (whether rendered in the same or different
viewports) per checkpoint
2.6. In SMIL 1.0
[SMIL], for example, the "
begin", "
and "
dur" attributes synchronize
presentation components. See also checkpoint 3.5, which involves client-driven content
META element, although this usage is not defined in HTML 4 [HTML4].
system-captions' test attribute.
system-captions' test attribute. Users should be able to indicate
a preference for receiving available audio descriptions. Note:
[SMIL] does not include a mechanism analogous to 'system-captions'
for audio descriptions, though [SMIL20] does, called
allows users to choose between subtitles and overdubs in multilingual
presentations. User agents should not interpret a value of
caption' for this test attribute as meaning that the user prefers
accessibility captions; that is the purpose of the
system-captions' test attribute. When subtitles and accessibility
captions are both available, users who are deaf may prefer to view captions, as
they generally contain information not in subtitles: information on music,
sound effects, who is speaking, etc.
Note: Some markup languages (such as HTML 4 [HTML4] and SMIL
require the author to provide conditional content for some elements (e.g., the
alt" attribute on the
alt attribute is missing on the
IMG element in HTML,
but the
title attribute is present, base the repair content on the
Note: In some authoring scenarios,
empty content (e.g.,
alt="" in HTML) may make an appropriate
text equivalent, such as when non-text content has no other
function than pure decoration, or when an image is part of a "mosaic" of
several images and does not make sense out of the mosaic. Refer to the Web
Content Accessibility Guidelines 1.0 [WCAG10] for more information about
text equivalents.
Note: For instance, an HTML user agent might allow
configuration so that the value of the "
alt" attribute is rendered in place of all
IMG elements (while other conditional content might be made
available through another mechanism). The user agent may offer multiple
configurations (e.g., a first configuration to render one type of conditional
content automatically, a second to render another type, etc.).
Note: This checkpoint is designed primarily to benefit users with serial access to content or who navigate sequentially, allowing them to skip portions of content that would be unusable if rendered as "garbage".
- Adopt a clearly visible (or audible), but unobtrusive mechanism to alert the user of missing resources.
- If missing characters are presented using their numeric representation, use the hexadecimal (not decimal) form since this is the form used in character set standards.
In addition to the techniques below, refer also to the section on user control of style.
Note: When background images are not rendered, they are considered conditional content. See checkpoint 2.3 for information about providing access to conditional content.
Note: See guideline 4 for additional requirements related to the control of rendered audio, video, and animated images. When these content types are not rendered, they are considered conditional content. See checkpoint 2.3 for information about providing access to conditional content.
Note: Animation (a rendering effect) differs from streaming (a delivery mechanism). Streaming content might be rendered as an animation (e.g., an animated stock ticker or vertically scrolling text) or as static text (e.g., movie subtitles, which are rendered for a limited time, but do not give the impression of movement).
MARQUEE element:
document.all.myBanner.scrollDelay = 100
Note: Scripts and applets may provide very useful functionality, not all of which causes accessibility problems. Developers should not consider that the user's ability to turn off scripts is an effective way to improve content accessibility; turning off scripts means losing the benefits they offer. Instead, developers should provide users with finer control over user agent or content behavior known to raise accessibility barriers. The user should only have to turn off scripts as a last resort.
NOSCRIPT in
HTML), alert the user to the presence of the alternative (and make it easily
available). If a user cannot access the script content, the alert will raise
the user's awareness of the alternative, which may be more accessible.
Note: For example, if an HTML author has used a
META element for automatic content retrieval, allow configuration to
override the automatic behavior with manual confirmation.
META element
http-equiv="refresh". This use of
META is not a
normative part of any W3C Recommendation and may pose interoperability
Note: When images are not rendered, they are considered conditional content. See checkpoint 2.3 for information about providing access to conditional content.
In addition to the techniques below, refer also to the section on user control of style.
ChooseFont function in the Comdlg32 library
creates the conventional utility that allows users to choose text (font) size.
DrawText API is the lower-level API for drawing text.
Note: For example, allow the user to specify that all text is to be rendered in a particular sans-serif font family.
ChooseFont function in the Comdlg32 library
creates the conventional utility that allows users to choose font
Note: User configuration of foreground and background colors may inadvertently lead to the inability to distinguish ordinary text from selected text, focused text, etc. See checkpoint 10.2 for more information about highlight styles.
background-color' attribute defined in section 3.3.1 of
[SMIL]). In the case of SMIL, the user agent would satisfy this
checkpoint by applying the user's preferred background color to all regions
(and to all
root-layout elements as well). SMIL 1.0 does not have
a way to specify the foreground color of text, so that portion of the
checkpoint would not apply.
ChooseColor function in the Comdlg32 library
creates the conventional utility that allows users to choose colors.
Note: The style exception of this checkpoint is based on the assumption that authors have satisfied the requirements of the "Web Content Accessibility Guidelines 1.0" [WCAG10] not to convey information through style alone (e.g., through color alone or style sheets alone).
background attribute.
speed attribute, which can be used to change the playback rate (as
well as forward or reverse direction) of any animation.
Note: The lower bound of three seconds is part of this checkpoint since control is not required for brief audio and animation clips, beeps, etc. Respect synchronization cues per checkpoint 2.6.
speed attribute, which can be used to change the playback
direction (forward or reverse) of any animation. See also the
accelerate and
decelerate attributes.
system-captions' test attribute.
Note: User agents should allow configuration of volume through available operating environment mechanisms.
Note: The user agent should satisfy this checkpoint by allowing the user to control independently the volumes of all audio sources (e.g., by implementing a general audio mixer type of functionality). See checkpoint 4.10 for information about controlling the volume of synthesized speech.
See also techniques for synthesized speech rendering.
Note: The range of synthesized speech rates offered by the speech synthesizer may depend on natural language.
Note: See checkpoint 4.8 for information about independent volume control of different sources of audio.
Note: Some speech synthesizers allow users to choose values for synthesized speech characteristics at a higher abstraction layer, i.e., by choosing from present options that group several characteristics. Some typical options one might encounter include: "voice ("adult male voice", "female child voice", "robot voice", etc.), "pitch", "stress", etc. Ranges for values may vary among speech synthesizers.
Note: This checkpoint is more specific than checkpoint 4.11. It requires support for the voice characteristics listed in the provisions of this checkpoint. Definitions for these characteristics are based on descriptions in section 19 of the Cascading Style Sheets Level 2 Recommendation [CSS2]; refer to that specification for additional informative descriptions. Some speech synthesizers allow users to choose values for synthesized speech characteristics at a higher abstraction layer, i.e., by choosing from present options distinguished by "gender", "age", "accent", etc. Ranges of values may vary among speech synthesizers.
Note: Definitions for the functionalities listed in the provisions of this checkpoint are based on descriptions in section 19 of the Cascading Style Sheets Level 2 Recommendation [CSS2]; refer to that specification for additional informative descriptions.
Note: By definition, the user agent's default style sheet is always present, but may be overridden by author or user styles. Developers should not consider that the user's ability to turn off author and user style sheets is an effective way to improve content accessibility; turning off style sheet support means losing the many benefits they offer. Instead, developers should provide users with finer control over user agent or content behavior known to raise accessibility barriers. The user should only have to turn off author and user style sheets as a last resort.
A[target=_blank]:before { content:"Open new window" }
Note: Generally, viewports open automatically as the result of instructions in content. See also checkpoint 5.1 (for control over changes of focus when a viewport opens) and checkpoint 6.6 (for programmatic notification of changes to the user interface).
target="_blank", open the window
according to the user's preference.
new" value of the "
show" attribute.
myWindow.open("example.com", "My New Window");
myWindow.close();. Some users with a cognitive disability may find it
disorienting if a viewport closes automatically. On the other hand, some users
with a physical disability may wish these same viewports to close automatically
(rather than being required to close them manually).
Note: For example, if users navigating links move to a portion of the document outside a graphical viewport, the viewport should scroll to include the new location of the focus. Or, for users of audio viewports, allow configuration to render the selection or focus immediately after the change.
Note: Examples of automatic form submission include: script-driven submission when the user changes the state of a particular form control associated with the form (e.g., via the pointing device), submission when all fields of a form have been filled out, and submission when a "mouseover" or "change" event occurs.
type="submit" and
type="image", and the
BUTTON element (section 17.5) with
As soon as the user attempts to navigate the menu, the "switchpage" function
opens a document in a new viewport. Try to avoid orientation problems that may
be caused by scripts bound to form elements.
<SELECT NAME="condition" onchange="switchpage(this)">
Note: Refer to the "Document Object Model (DOM) Level 2 Core Specification" [DOM2CORE] for information about HTML and XML versions covered. This checkpoint is stands apart from checkpoint 6.1 to emphasize the distinction between what information is required and how to provide access to that information.
Note: This checkpoint addresses content not covered by checkpoint 6.1 and checkpoint 6.2.
DrawText API is the lower-level API for
drawing text.
Note: User agents should provide programmatic access to additional useful information about rendered content that is not available through the APIs required by checkpoints 6.2 and 6.3, including the correspondence (in both directions) between graphical objects and their source in the document object, and information about the role of each graphical object.
Note: APIs used to satisfy the requirements of this checkpoint may be independent of a particular operating environment (e.g., the W3C DOM), conventional APIs for a particular operating environment, conventional APIs for programming languages, plug-ins, virtual machine environments, etc. User agent developers are encouraged to implement APIs that allow assistive technologies to interoperate with multiple types of software in a given operating environment (user agents, word processors, spreadsheet programs, etc.), as this reuse will benefit users and assistive technology developers. User agents should always follow operating environment conventions for the use of input and output APIs.
Note: For instance, provide programmatic notification when user interaction in one frame causes automatic changes to content in another.
Note: An operating environment may define more than one conventional API for the keyboard. For instance, for Japanese and Chinese, input may be processed in two stages, with an API for each.
Note: Support for character encodings is important so that
text is not "broken" when communicated to assistive technologies. For example,
the DOM Level 2 Core Specification [DOM2CORE], section 1.1.5
requires that the
DOMString type be encoded using UTF-16.
Finally, and quite significantly, all strings passed through all COM interfaces (and, at least on Microsoft platforms, all COM APIs) are Unicode strings. There simply is no other reasonable way to get interoperable objects in the face of (i) location transparency, and (ii) a high-efficiency object architecture that does not in all cases intervene system-provided code between client and server. Further, this burden is in practice not large.
Note: Refer to the "Document Object Model (DOM) Level 2 Style Specification" [DOM2STYLE] for information about CSS versions covered.
Note: For example, the programmatic exchange of information required by other checkpoints in this document should be efficient enough to prevent information loss, a risk when changes to content or user interface occur more quickly than the communication of those changes. Timely exchange is also important for the proper synchronization of alternative renderings. The techniques for this checkpoint explain how developers can reduce communication delays. This will help ensure that assistive technologies have timely access to the document object model and other information that is important for providing access.
Note: See checkpoints 9.1 and 9.2 for more information about content focus and user interface focus.
Note: See checkpoint 11.5 for information about the user agent's default input configuration.
Note: For example, in some operating environments, when a functionality may be triggered through a menu and through the keyboard, the developer may design the menu entry so that the character of the activating key is also shown. See checkpoint 11.5 for information about the user agent's default input configuration.
Note: For instance, for markup, the user agent may conform to HTML 4 [HTML4], XHTML 1.0 [XHTML10], and/or XML 1.0 [XML]. For style sheets, the user agent may conform to CSS ([CSS1], [CSS2]). For mathematics, the user agent may conform to MathML 2.0 [MATHML20]. For synchronized multimedia, the user agent may conform to SMIL 1.0 [SMIL].
Note: For example, when two frames of a frameset contain enabled elements, allow the user to make the content focus of either frame the current focus. Note that viewports "owned" by plug-ins that are part of a conformance claim are also covered by this checkpoint. See checkpoint 7.1 for information about implementing content focus according to operating environment conventions.
Note: See checkpoint 7.1 for information about implementing user interface focus according to operating environment conventions.
Note: In addition to forward sequential navigation, the user agent should also allow reverse sequential navigation. See checkpoint 9.9 for information about structured navigation. See checkpoints 5.1 and 6.6 for more information about focus changes.
isFocusTraversable method returns
true. A component can be removed from the navigation order by extending the
component, overloading this method, and returning false.
myWindow.history.go( -2 );
location.href = "http://example.com/"
Note: For instance, in this configuration for an HTML
document, do not activate any handlers for the '
onblur', or '
onchange' attributes. In this
configuration, user agents should still apply any stylistic changes (e.g., highlighting) that may occur when there is
a change in content focus.
Note: For example, allow the user to query the element with content focus for the list of input device event types, or add them directly to the sequential navigation order described in checkpoint 9.3. See checkpoint 1.2 for information about activation of event handlers associated with the element with focus.
onmouseover and
onfocus events). When the user
agent recognizes the same handler for two event types, present only one of them
to avoid confusion.
EventTarget.canTrigger/EventTarget.isRegisteredHere and
EventTarget.canTrigger/Event.isRegisteredHere. The first method provides
information about the target node only, the second about whether there are
handlers on any node in the path between the target node and the root
Note: If the user has not indicated a start position for the search, the search should start from the beginning of content. Per checkpoint 7.3, use operating environment conventions for indicating the result of a search (e.g., selection or content focus).
visibility="hidden"), or equivalent text for elements with such
properties (such as "
alt" text for an image that has
Note: This specification intentionally does not identify which "important elements" must be navigable as this will vary by specification. What constitutes "efficient navigation" may depend on a number of factors as well, including the "shape" of content (e.g., sequential navigation of long lists is not efficient) and desired granularity (e.g., among tables, then among the cells of a given table).
LINK (if rendered),
TEXTAREA, and
UL. HTML also allows
authors to specify keyboard configurations ("accesskey", "tabindex"), which can
serve as hints about what the author considers important.
title" attribute specified. Note: Starting in
HTML 4, the MAP element allows block content, not just AREA
Note: For example, allow the user to navigate only paragraphs, or only headings and paragraphs, or to suppress and restore navigation bars, to navigate within and among tables and table cells, etc.
TBODY element, the
'overflow' property of CSS 2 ([CSS2], section 11.1.1) may be used
to create a scrollable area.
tbody { height: 10em; overflow: auto }
TH, and
elements, the table attributes "summary", "abbr", "headers", "scope", and
"axis" also provide information about relationships among cells and headers.
For more information, see the section on table
Note: Examples of highlight mechanisms for selection and content focus include foreground and background color variations, underlining, distinctive synthesized speech prosody, border styling, etc. Because the selection and focus change frequently, user agents should not highlight them using mechanisms (e.g., font size variations) that cause content to reflow, as this may disorient the user. Graphical highlight mechanisms that generally do not rely on rendered text foreground and background color alone include underlines or border styling. Per checkpoint 7.1, follow operating environment conventions that benefit accessibility when implementing the selection and content focus. For instance, if specified at the level of the operating environment, inherit the user's preferences for selection styles.
*selectForeground and
The following rule will cause links with focus to appear with a blue background and yellow text.
A:focus { background: blue; color: yellow }
The following rule will cause
TEXTAREA elements with focus to
appear with a particular focus outline:
TEXTAREA:focus { outline: thick black solid }
ChooseFont and
ChooseColor in techniques for checkpoint 4.1, checkpoint 4.2, and checkpoint 4.3.
ChooseFont is also used to
choose some text decorations in Windows.
H6) is a label
for the section that follows it, a
CAPTION is a label for a table,
the "
title" attribute is a label for its element, etc.
Note: This outline view will provide the user with a simplified view of content (e.g, a table of contents). For information about what constitutes the set of important structural elements, see the Note following checkpoint 9.9. By making the outline view navigable, it is possible to satisfy this checkpoint and checkpoint 9.9 together: allow users to navigate among the important elements of the outline view, and to navigate from a position in the outline view to the corresponding position in a full view of content. See checkpoint 9.10 for additional configuration options.
CAPTION element is a label for
title" attribute is a label for many elements.
H6 elements are labels for sections that
LABEL element is a label for the form element
LEGEND element is a label for a set of form elements
TH element is a label for a row/column of table
TITLE element is a label for the document.
LEGEND or
OPTGROUP in HTML) along with their
Note: See checkpoint 7.1 for information about implementing highlight mechanisms according to operating environment conventions.
THEAD and
TBODY elements of HTML 4 ([HTML4], section
11.2.3) and the
'overflow' property of CSS 2 ([CSS2], section 11.1.1).
H1, etc.
FIELDSET in HTML).
Note: For example, for HTML documents, provide a view of
keyboard bindings specified by the author through the "
attribute. The intent of this checkpoint is to centralize information about
author-specified bindings so that the user does not have to read an entire
document to look for available bindings.
Note: See checkpoint 11.5 for default input configuration requirements and checkpoint 12.3 for information about their documentation.
Note: Because single-key access is so important to some users with physical disabilities, user agents should ensure that: (1) most keys of the physical keyboard may be configured for single-key bindings, and (2) most functionalities of the user agent may be configured for single-key bindings. For information about access to user agent functionality through a keyboard API, see checkpoint 6.7.
Note: This checkpoint does not make any requirements about the ease of use of default input configurations, though clearly the default configuration should include single-key bindings and allow easy operation. Ease of use is addressed by the configuration requirements of checkpoint 11.3.
NOFRAMES element when the support/documentation is
presented in a
Note: The help system should include discussion of user agent features that benefit accessibility. The user agent should satisfy this checkpoint by providing both centralized and integrated views of accessibility features in the documentation.
Note: Documentation should warn the user whenever the default input configuration is inconsistent with conventions of the operating environment.
Note: Developers are encouraged to integrate descriptions of accessibility features into the documentation alongside other features, in addition to providing a centralized view.
This section presents general techniques that may be relevant to more than one checkpoint. This section is not written in terms of the requirements of the checkpoints. Instead, it is organized according to other topics that should also be familiar to user agent designers.
User agents need to ensure that users have access to content, either rendered through the user interface or made available to assistive technologies through an API. While providing serial access to a stream of content would satisfy this requirement, this would be analogous to offering recorded music on a cassette: other technologies exist (e.g., CD-ROMs) that allow direct access to music. It is just as important for user agents to allow users to access Web content efficiently, whether the content is being rendered as a two-dimensional graphical layout, an audio stream, or series of lines of braille. Providing efficient access to content involves:
These topics are addressed below.
Note: Throughout this document, the term context menu refers to a user interaction mechanism whereby:
When used properly, markup languages structure content in ways that allow user agents to communicate that structure across different renderings. A table describes relationships among cells and headers. Graphically, user agents generally render tables as a two-dimensional grid. However, relationships also have to be apparent for users with serial access to content or who navigate sequentially, otherwise users may not understand the purpose of the table and the relationships among its cells (see the section on table techniques). User agents need to render content in ways that allow users to understand the underlying document structure, which may consist of headings, lists, tables, synchronized multimedia, link relationships, etc. Providing alternative renderings (e.g., an outline view) will also help users understand document structure.
Note: Even though the structure of a language like HTML may be defined by a document type definition (DTD) or a schema, user agents may convey structure according to a "more intelligent" document model when that model is well-known. For instance, in the HTML 4 [HTML4] and XHTML 1.0 [XHTML10] DTDs, heading elements (H1 - H6) do not nest, but presenting the document as nested headings may convey the document's structure more effectively than as a flat list of headers.
The guidelines emphasize the importance of navigation as a way to provide efficient access to content. Navigation allows users to access content more efficiently and, when used in conjunction with selection and focus mechanisms, allows users to query content for metadata. For instance, blind users often navigate a document by skipping from link to link, deciding whether to follow each link based on metadata about the link. User agents can help them decide whether to follow a link by allowing them to query each focused link for the link text, title information, information about whether the link has been visited, etc. While much of this information may be rendered, the information has to also be available to assistive technologies.
For example, the Amaya browser/editor [AMAYA] makes available all attributes and their values to the user through a context menu. The user selects an element and opens an attribute menu that shows which attributes are available for the element and which have been assigned values. The user may read or write values to attributes (since Amaya is an editor as well as a browser). Information about attributes is also available through Amaya's structured view, which renders the document tree as structured text.
The selection may be widened (moved to the nearest node one level up the document tree) by pressing the Escape key; this is a form of structured navigation based on the underlying document object model.
Users may want to select content based on structure alone (as offered by Amaya) but also based on how the content has been rendered. For instance, most user agents allow users to select ranges of rendered text that may cross "element boundaries" (e.g., to select part of a paragraph that includes a phrase that is emphasized).
Authors and user agents provide context to users through content, structure, navigation mechanisms, and query mechanisms. Titles, dimensions, dates, relationships, the number of elements, and other metadata all help orient the user, particularly when available as text. For instance, user agents can help orient users by allowing them to request that document headings and lists be numbered. See also the section on table techniques, which explains how user agents can offer table navigation and the ability to query a table cell for information about the cell's row and column position, associated header information, etc.
To ensure accessibility, users need to be able to configure the style of rendered content and the user interface. Author-specified styles, while important, may make content inaccessible to some users. User agents need to allow users to increase the scale of rendered text, to change colors and color combinations, to slow down multimedia presentations, etc.
Cascading Style Sheets (CSS, defined in [CSS1] and [CSS2]) give authors design flexibility and allow users to control important aspects of content style; see checkpoint 4.14 for information about allowing users to choose from among available style sheets. CSS includes mechanisms for tailoring rendering for a particular output medium, including audio, braille, screen, and print.
document.all.myElement style.color = "red";
User agents make links accessible by providing navigation to links, helping users decide whether to follow them, and allowing interaction in a device-independent manner. Link techniques include the following:
User agents can make lists accessible by ensuring that list structure – and in particular, embedded list structure – is available through navigation and rendering.
1. 1. 2. 1. 3. 2. 1.
which might be serialized for synthesized speech or braille as "1, 1, 2, 1, 2, 3, 2, 1".
The following CSS 2 style sheet (taken from CSS 2, section 12.5) shows how to specify compound numbers for nested lists created with either UL or OL elements. Items are numbered as "1", "1.1", "1.1.1", etc.
<STYLE type="text/css"> UL, OL { counter-reset: item } LI { display: block } LI:before { content: counters(item, "."); counter-increment: item } </STYLE>
End example.
The HTML TABLE element was designed to represent relationships among data ("data" tables). Even when authored well and used according to format specification, tables may pose problems for users with disabilities for a number of reasons:
For these situations, user agents may assist these users by providing table navigation mechanisms and supplying context that is present in a two-dimensional rendering (e.g., the cells surrounding a given cell).
To complicate matters, many authors use tables to lay out Web content ("layout" tables). Not only are table structures used to arrange objects horizontally and vertically on the screen, table elements such as TH (table header) in HTML are used to change the style of text (as table headers are often rendered in bold fonts) rather than to indicate a true table header. These practices make it difficult for assistive technologies to rely on markup to convey document structure. Consequently, assistive technologies often resort to interpreting the rendered content, even though the rendered content has "lost" information encoded in the markup. For instance, when an assistive technology "reads" a table from its graphical rendering, the contents of multiline cells may become intermingled. For example, consider the following table:
This is the top left cell This is the top right cell of the table. of the table. This is the bottom left This is the bottom right cell of the table. cell of the table.
Screen readers that read rendered content line by line would read the table cells incorrectly as "This is the top left cell This is the top right cell". So that assistive technologies are not required to gather incomplete information from renderings, these guidelines require that user agents provide access to content through an API (see checkpoint 6.3).
The following sections discuss techniques for providing improved access to tables.
Users with serial access to content or who navigate sequentially cannot gather information "at a glance" about a two-dimensional table. User agents can make tables more accessible by providing the user with table metadata such as the following:
CAPTION element in HTML) or summary
information (the "
summary" attribute in HTML).
When navigating, quick access to table metadata will allow users to decide whether to navigate within the table or skip over it. Other techniques:
A linear rendering of tables – cells presented one at a time, row by row or column by column – may be useful, but generally only for simple tables. For more complex tables, user agents need to convey more information about relationships among cells and their headers. A linear rendering of a table may be useful as an equivalent for a multi-dimensional table.
Note: The following techniques apply to columns as well as rows. The elements listed in this section are HTML 4.01 table elements ([HTML4], section 11).
TR) at a time, beginning with any
column header (
TH). If a header is associated with more than one
row, offer that header for each row concerned.
TD) with their associated headers. Allow the
user to configure how often headers are rendered (e.g., by implementing the
speak-header' property in CSS 2 [CSS2], section 17.7.1). Note also
the "
abbr" attribute in HTML 4 specifies
abbreviated headers for synthesized speech and other rendering ([HTML4], section
11.2.6). See also information about cell headers
later in this section.
The most important aspect of rendering a table cell is that the cell's contents be rendered faithfully and be identifiable as the contents of a single cell. However, user agents may provide additional information to help orient the user:
TH cells, the
interpretation of the corner cell as an
TD or
TH should not contribute to the set
of headings for cells in that row and column.
Properly constructed data tables distinguish header cells from data cells.
How headers are associated with table cells depends on the markup language. The
following algorithm is based on the
HTML 4.01 algorithm to calculate header information ([HTML4], section
11.4.3). For the sake of brevity, it assumes a left-to-right ordering, but will
also work (with minor modifications) for right-to-left tables (refer to the
dir" attribute of HTML 4 [HTML4], section
8.2). For a given cell:
cells. Then search upwards from the cell's position to find column header
cells. The search in a given direction stops when the edge of the table is
reached or when a data cell is found after a header cell. If no headers are
found in either direction (left or up), search in the other directions (right
or down).
abbr" attribute value ([HTML4], section 11.2.6).
rowspan="R", sufficient to extend into the current
colspan="C", sufficient to extend into the
current column containing the
TD cell.
Not all data tables include proper header markup, which the user agent may be able to detect. Some repair strategies for finding header information include the following:
Other repair issues to consider:
TH cells on both the left and right of the
TH cells with "rowspan" set: consider the content of
TH cells for each of the N-1 rows below the one
containing that
TH content.
TH surrounded by
TD elements
makes it difficult to know whether the header applies to cells to its left or
right in the same row (or in both directions) or cells above or below it in the
same column (or in both directions).
element to which they apply.
TH element with "
colspan" set needs to be
included in the list of
TH elements for the N-1 columns to its
To permit efficient access to tables, user agents should allow users to navigate to tables and within tables, to select individual cells, and to query them for information about the cell and the table as a whole.
One way to make an image map accessible to some users (e.g., users with blindness) is to render the links it contains as text links. This allows assistive technologies to render the links as synthesized speech or braille, and benefits users with slow access to the Web and users of small Web devices that do not support images but can support hypertext. User agents may allow users to toggle back and forth between a graphical mode for image maps and a text mode.
To construct a text version of an image map in HTML:
AREA in the map, if (not empty conditional text content is
available (e.g., the "
alt" attribute), use it as the content of a
generated link.
alt=''"), do not render the link.
Furthermore, user agents that render a text image map instead of an image may preface the text image map with inline metadata such as:
Allow users to suppress, shrink, and expand text versions of image maps so that they may quickly navigate to an image map (which may be, for example, a navigation tool bar) and decide whether to "expand" it and follow the links of the map. The metadata listed above will allow users to decide whether to expand the map. Ensure that the user can expand and shrink the map and navigate its links using the keyboard and other input devices.
HTML frames (see, for example, the FRAME and IFRAME elements in HTML 4 [HTML4]) were originally designed so that authors could divide up graphic real estate and allow the pieces to change independently (e.g., selecting an entry in a table of contents in one frame changes the contents of a second frame). While frames are not inherently inaccessible, they raise some accessibility issues:
To name a frame in HTML, use the following algorithm:
title" attribute on
FRAME; or if not
name" attribute on
FRAME; or if not
TITLE element of the source HTML document); or
longdesc" refers to in HTML), or
To make frames accessible, user agents should do the following:
NOFRAMES element but the individual frames have associated long
descriptions ("longdesc"):
H2 heading,
followed by the content of the associated long description.
noresize", "
scrolling", and
The following screen shot illustrates how Home Page Reader [HPR] renders a frameset by allowing the user to navigate (on the left side) to each of five frames in a frameset.
The next screen shot illustrates how the user agent can provide information about the number and structure of frames in the user agent user interface.
To make a form accessible, the user agent needs to ensure that:
LEGEND or
OPTGROUP in HTML) along with their
Provide the following information about forms on demand:
In conjunction with navigation:
for" attribute on
LABEL in HTML), make available
label information when the user navigates among the form elements.
TEXTAREA status line message, enables the user to invoke an external
editor defined in the local Lynx configuration file (lynx.cfg).
Provide the following information about the elements in a form on demand (e.g., for the element with focus):
tabindex" in HTML). This is important since:
FIELDSET element ([HTML4], section 17.10), which
allows authors to group thematically related elements and labels. The
LEGEND element ([HTML4], section 17.10) assigns a
caption to a
FIELDSET. For example, the
element might identify a
FIELDSET of radio buttons as "Connection
Rate". Each button could have a
LABEL element ([HTML4], section 17.9.1) stating a
rate. When it receives content focus, identify the radio button as "Connection
Rate: Radio button X of Y: 28.8kpbs", where "Y" represents the total number of
radio buttons in the grouping and "28.8kbps" is the information contained in
TEXTAREA element. This allows users to use all the features of
the external editor: macros, spell-checkers, validators, known input
configurations, autosave features, etc.
OPTGROUP and each individual
OPTION, and re-associate
them with the generated checkboxes. The
LABEL defined for the
OPTGROUP should be converted into a
LEGEND for the
FIELDSET, and each checkbox should retain the
LABEL defined for the corresponding
OPTION. Lynx [LYNX] does this for
SELECT elements that have the "
attribute specified.
User agents may help orient users by generating additional content that "announces" a context change. This may be done through CSS 2 [CSS2] style sheets using a combination of selectors (including the ':before' and ':after' pseudo-elements described in section 12.1) and the 'content' property (section 12.2).
For instance, the user might choose to hear "language:German" when the natural language changes to German and "language:default" when it changes back. This may be implemented in CSS 2 with the ':before' and ':after' pseudo-elements ([CSS2], section 5.12.3)
With the following definition in the style sheet:
[lang|=es]:before { content: "start Spanish "; } [lang|=es]:after { content: " end Spanish"; }
the following HTML example:
<p lang="es" class="Spanish"> <a href="foo_esp.html" hreflang="es">Esta pagina en español</a></p>
might be spoken "start Spanish _Esta pagina en espanol_ end Spanish". Refer also to information on matching attributes and attribute values useful for language matching in CSS 2 ([CSS2], section 5.8.1).
The following example uses style sheets to distinguish visited from unvisited links with color and a text prefix.
The phrase "Visited link:" is inserted before every visited link:
A:link { color: red } /* Unvisited links */ A:visited { color: green } /* Visited links */ A:visited:before { content: "Visited link: " }
To hide content, use the CSS 'display' or 'visibility' properties ([CSS2], sections 9.2.5 and 11.2, respectively). The 'display' property suppresses rendering of an entire subtree. The 'visibility' property causes the user agent to generate a rendering structure, but the content is invisible.
The following XSLT style sheet (excerpted from the XSLT Recommendation [XSLT], Section 7.7) shows how one might number H4 elements in HTML with a three-part label.
<xsl:template match="H4"> <fo:block> <xsl:number level="any" from="H1" count="H2"/> <xsl:text>.</xsl:text> <xsl:number level="any" from="H2" count="H3"/> <xsl:text>.</xsl:text> <xsl:number level="any" from="H3" count="H4"/> <xsl:text> </xsl:text> <xsl:apply-templates/> </fo:block> </xsl:template>
End example.
When generating repair content, user agent developers should consider the following issues:
See also the section on table cell header repair strategies. Refer also to the W3C document "Techniques for Authoring Tool Accessibility Guidelines 1.0" [ATAG10-TECHS].
User agents need to make dynamic content accessible to users who may be disoriented by changes in content, who may have a physical disability that prevents them from interacting with a document within a time interval specified by the author, or whose user agent does not support scripts or applets. Not only do user agents make available equivalents to dynamic content (e.g., audio, animations), they have to allow users to turn off scripts, to stop animations, adjust timing parameters, etc. Some user agents also allow users to turn off scripts for security reasons.
Certain elements of a markup language may have associated event handlers
that are activated when certain events occur. User agents need to be able to
identify those elements with event handlers statically associated (i.e.,
associated in the content, not in a script). In
HTML 4 ([HTML4], section 18.2.3),
intrinsic events are specified by the attributes beginning with the prefix
"on": "
onblur", "
onchange", "
ondblclick", "
onkeydown", "
onkeyup", "
", "onmousedown",
onmousemove", "
onmouseover", "
onmouseup", "
onselect", "
onsubmit", and
Techniques for providing access to scripts include the following:
onclick" and "
When a user agent loads an Java applet, it should support the Java system conventions for loading an assistive technology (see the appendix on loading assistive technologies for DOM access). If the user is accessing the applet through an assistive technology, the assistive technology should alert the user when the applet receives content focus as this will likely result in the launch of an associated plug-in or browser-specific Java Virtual Machine. The user agent then needs to turn control of the applet over to the assistive technology. User agents need to make conditional content available to the assistive technology. Applets generally include an application frame that provides title information.
User agents that allow users to modify default input configurations need to account for configuration information from several sources: user agent defaults, user preferences, author-specified configurations, and operating environment conventions. Some examples include:
To the user, the most important information is the final configuration once all sources have been cascaded (combined) and all conflicts resolved. Knowing the default configuration is also important; checkpoint 12.3 requires that the default configuration be documented. The user may also want to know how the current configuration differs from the default configuration and what configuration in the viewport with the current focus comes from the author. This information may also be useful to technical support personnel who may be assisting users.
In general, user preferences should override other configurations, however this may not always be desirable. For example, users should be prevented from configuring the user agent in a way that would interfere with important functionalities such as quitting the user agent or reconfiguring it.
Some options for resolving conflicts:
Refer to the section on restricted functionality and conformance in UAAG 1.0 for more information about limitations in functionality due to content.
The following techniques apply to user agents that render content as synthesized speech.
Users with serial access to content or who navigate sequentially to content may have difficulty interacting with content in two-dimensional space (e.g., to move a pointing device). Using the keyboard to move the pointing device may help some users, but this technique usually requires a significant amount of visual feedback as well as physical dexterity, both of which may not be possible for users with some disabilities.
To illustrate ways to reduce dependency on spatial interactions, consider a Web site for travel through Europe. The author provides a map of Europe and allows users to select regions they wish to visit using a pointing device. This type of application is very convenient to some users, but may be inaccessible to others. Authors can design such content to place the emphasis on objects (in this case European countries) rather than screen coordinates. In HTML, for example, authors should use client-side image maps instead of server-side image maps.
When this is done, the user agent can present the list of countries in an alternative fashion (e.g., as a list of links or menu entries) for users who may find it difficult to select countries with the pointing device. This type of interface generally benefits all users (e.g., some users who may not recognize countries by shape or flag, some users may prefer the keyboard, some users may have images turned off, the text may be searched, etc.).
The following techniques may be considered when integrating accessibility features and internationalization.
For more information about content internationalization, refer to W3C's "Character Model for the World Wide Web" [CHARMOD] and the Unicode Consortium's Unicode specification [UNICODE].
This matrix summarizes which checkpoints are expected to benefit users with certain types of disabilities. For more information about types of disabilities, assistive technologies, access strategies, and more, refer to W3C's "How People with Disabilities Use the Web" [PWD-USE-WEB].
Several operating systems include built-in accessibility features designed to assist individuals with disabilities. Despite operating systems differences, the built-in accessibility features use a similar naming convention and offer similar functionalities, within the limits imposed by each operating system (or particular hardware platform). The following is a list of built-in accessibility features common to several operating environments:
The next three built-in accessibility features are not as commonly available as the above group of features, but are included here for completeness and future compatibility.
The next accessibility feature listed here is not considered to be a built-in accessibility feature (since it only provides an alternative input channel) and is presented here only for completeness and future compatibility.
The following accessibility features can be adjusted from the Accessibility Options Control Panel:
Additional accessibility features available in Windows 98:
The following accessibility features can be adjusted from the Easy Access Control panel. Note: The Apple naming convention for accessibility features is to put spaces between the terms (e.g., "Sticky Keys" instead of "StickyKeys").
The following accessibility features can be adjusted from the Keyboard Control Panel.
The following accessibility feature can be adjusted from the Sound or Monitors and Sound Control Panel (depending on operating system version).
Additional accessibility features available for the Macintosh OS:
The following accessibility features can be adjusted from the AccessX graphical user interface X client on some DEC, SUN, and SGI operating systems. Other operating systems supporting XKB may require command line interaction.
Note: AccessX became a supported part of the X Window System X Server with the release of the X Keyboard Extension in version X11R6.1.
The following accessibility features are available from a freeware program called AccessDOS, which is available from several Internet Web sites including IBM, Microsoft, and the Trace Center, for either PC-DOS or MS-DOS versions 3.3 or higher.
Many of the checkpoints in the guidelines require a "host" user agent to communicate information about content and the user interface to assistive technologies. This appendix explains how developers can ensure the timely exchange of this information (see checkpoint 6.10). The techniques described here include:
The first two techniques are similar, differing in the amount of, or capability of, the assistive technology loaded in the same process or address space as the host user agent. These techniques are likely to provide faster access to the document object model since they will not be subject to inter-process communication overhead.
First, the host user agent needs to know which assistive technology to load. One technique for this is to store a reference to an assistive technology in a system registry file or, in the case of Java, a properties file. Registry files are common among many operating environments:
Here is an example entry for Java:
In Microsoft Windows, a similar technique could be followed by storing the name of a Dynamic Link Library (DLL) for an assistive technology in a designated assistive technology key name/assistive technology pair.
Here is an example entry for Windows:
HKEY_LOCAL_MACHINE\Software\Accessibility\DOM "ScreenReader, VoiceNavigation"
Once the assistive technology has been registered, any other user agent can determine whether it needs to be loaded and then load it. Once loaded, the assistive technology can monitor the document object model as needed.
On a non-Java platform, a technique to do this would be to create a separate thread with a reference to the document object model using a DLL. This new thread will load the DLL and call a specified DLL entry name with a pointer to the document object model interface. The assistive technology process will then run as long as required.
The assistive technology has the option to either:
In the future, it will be necessary to provide a more comprehensive reference to the application that not only provides direct navigation to its client area document object model, but also multiple document object models that it is processing and an event model for monitoring them.
Java can facilitate timely access to accessibility components. In this example, an assistive technology running on a separate thread monitors user interface events such as focus changes. When focus changes, the assistive technology is alerted of which component object has focus. The assistive technology can communicate directly with all components in the application by walking the parent/child hierarchy and connecting to each component's methods and monitor events directly. In this case, an assistive technology has direct access to component specific methods as well as those provided for by the Java Accessibility API. There is no reason that a document object model interface to user agent components could not be provided via Java.
In Java 1.1.x, Sun's Java access utilities load an assistive by monitoring the Java awt.properties file for the presence of assistive technologies and loads them as shown in the following code example:
import java.awt.*; import java.util.*; String atNames = Toolkit.getProperty("AWT.assistive_technologies",null); if (atNames != null) { StringTokenizer parser = new StringTokenizer(atNames," ,"); String atName; while (parser.hasMoreTokens()) { atName = parser.nextToken(); try { Class.forName(atName).newInstance(); } catch (ClassNotFoundException e) { throw new AWTError("Assistive Technology not found: " + atName); } catch (InstantiationException e) { throw new AWTError("Could not instantiate Assistive" + " Technology: " + atName); } catch (IllegalAccessException e) { throw new AWTError("Could not access Assistive" + " Technology: " + atName); } catch (Exception e) { throw new AWTError("Error trying to install Assistive" + " Technology: " + atName + " " + e); } } }
In the above code example, the function
Class.forName(atName).newInstance() creates a new instance of the
assistive technology. The constructor for the assistive technology will then be
responsible for monitoring application component objects by monitoring system
In the following code example, the constructor for the assistive technology,
AccessEngine, adds a focus change listener using Java
accessibility utilities. When the assistive technology is alerted that an
object has received focus, it has direct access to that object. If the Object,
o, has implemented a document object model interface, the
assistive technology will have direct access to the document object model in
the same process space as the application.
import java.awt.*; import javax.accessibility.*; import com.sun.java.accessibility.util.*; import java.awt.event.FocusListener; class AccessEngine implements FocusListener { public AccessEngine() { //Add the AccessEngine as a focus change listener SwingEventMonitor.addFocusListener((FocusListener)this); } public void focusGained(FocusEvent theEvent) { // get the component object source Object o = theEvent.getSource(); // check to see if this is a dom component if (o instanceof DOM) { ... } } public void focusLost(FocusEvent theEvent) { // Do Nothing } }
In this example, the assistive technology has the option of running stand-alone or acting as a cache for a bridge that communicates with a main assistive technology running outside the Java virtual machine.
In order to attach to a running instance of Internet Explorer 4.0, you can use a Browser Helper Object ([BHO]), which is a DLL that will attach itself to every new instance of Internet Explorer 4.0 [IE-WIN] (only if you run iexplore.exe). You can use this feature to gain access to the object model of Internet Explorer and to monitor events. This can be tremendously helpful when many method calls need to be made to Internet Explorer, as each call will be executed much more quickly than the out of process case.
There are some requirements when creating a Browser Helper Object:
IObjectWithSite::SetSite() method must be implemented. It
is through this method that your application receives a pointer to Internet
IUnknown. Internet Explorer actually passes a pointer
IWebBrowser2 but the implementation of
receives a pointer to
IUnknown. You can use this
IUnknown pointer to automate Internet Explorer or to sink events from
Internet Explorer.
To provide native Microsoft Windows assistive technologies access to Java applications without creating a Java native solution, Sun Microsystems provides the "Java Access Bridge." This bridge is loaded as an assistive technology as described in the section on loading assistive technologies for direct navigation of the document object model. The bridge uses a Java Native Invocation (JNI) to Dynamic Link Library (DLL) communication and caching mechanism that allows a native assistive technology to gather and monitor accessibility information in the Java environment. In this environment, the assistive technology determines that a Java application or applet is running and communicates with the Java Access Bridge DLL to process accessibility information about the application/applet running in the Java Virtual Machine.
Access to application specific data across process boundaries or address spaces might be costly in terms of performance. However, there are other reasons to consider when accessing the document object model that might lead a developer to wish to access it from their own process or memory address space. One obvious protection this method provides is that, if the user agent fails, it does not disable the user's assistive technology as well. Another consideration would be legacy systems, where the user relies on their assistive technology for access to software other than the user agent, and thus would have their application loaded all the time.
There are several ways to gain access to the user agent's document object model. Most user agents support some kind of external interface, or act as a mini-server to other applications running on the desktop. Internet Explorer [IE-WIN] is a good example of this, as IE can behave as a component object model (COM) server to other applications. Mozilla [MOZILLA], the open source release of Navigator also supports cross-platform COM (XPCOM).
The following example illustrates the use of COM to access the IE object
model. This is an example of how to use COM to get a pointer to the
WebBrowser2 module, which in turn enables access to an interface/pointer
to the document object, or IE document object model for the content.
/* first, get a pointer to the WebBrowser2 control */ if (m_pIE == NULL) { hr = CoCreateInstance(CLSID_InternetExplorer, NULL, CLSCTX_LOCAL_SERVER, IID_IWebBrowser2, (void**)&m_pIE); /* next, get a interface/pointer to the document in view, this is an interface to the document object model (DOM)*/ void CHelpdbDlg::Digest_Document() { HRESULT hr; if (m_pIE != NULL) { IDispatch* pDisp; hr = m_pIE->QueryInterface(IID_IDispatch, (void**) &pDisp); if (SUCCEEDED(hr)) { IDispatch* lDisp; hr = m_pIE->get_Document(&lDisp); if (SUCCEEDED(hr)) { IHTMLDocument2* pHTMLDocument2; hr = lDisp->QueryInterface(IID_IHTMLDocument2, (void**) &pHTMLDocument2); if (SUCCEEDED(hr)) { /* with this interface/pointer, IHTMLDocument2*, you can then work on the document */ IHTMLElementCollection* pColl; hr = pHTMLDocument2->get_all(&pColl); if (SUCCEEDED(hr)) { LONG c_elem; hr = pColl->get_length(&c_elem); if (SUCCEEDED(hr)) { FindElements(c_elem, pColl); } pColl->Release(); } pHTMLDocument2->Release(); } lDisp->Release(); } pDisp->Release(); } } } }
For a working example of this method, refer to HelpDB [HELPDB].
This glossary is normative. However, some terms (or parts of explanations of terms) may not have an impact on conformance.
Note: In this document, glossary terms generally link to the corresponding entries in this section. These terms are also highlighted through style sheets and identified as glossary terms through markup.
The effect of activation depends on the type of the user interface control. For instance, when a link is activated, the user agent generally retrieves the linked Web resource. When a form element is activated, it may change state (e.g., check boxes) or may take user input (e.g., a text entry field).
Implementing APIs that are independent of a particular operating environment (as are the W3C DOM Level 2 specifications) may reduce implementation costs for multi-platform user agents and promote the development of multi-platform assistive technologies. Implementing conventional APIs for a particular operating environment may reduce implementation costs for assistive technology developers who wish to interoperate with more than one piece of software running on that operating environment.
A "device API" defines how communication may take place with an input or output device such as a keyboard, mouse, video card, etc.
In this document, an "input/output API" defines how applications or devices communicate with a user agent. As used in this document, input and output APIs include, but are not limited to, device APIs. Input and output APIs also include more abstract communication interfaces than those specified by device APIs. A "conventional input/output API" is one that is expected to be implemented by software running on a particular operating environment. For example, on desktop computers today, the conventional input APIs are for the mouse and keyboard. For touch screen devices or mobile devices, conventional input APIs may include stylus, buttons, voice, etc. The graphical display and sound card are considered conventional output devices for a graphical desktop computer environment, and each has an associated API.
For example, screen reader software is an assistive technology because it relies on browsers or other software to enable Web access, particularly for people with visual and learning disabilities.
Examples of assistive technologies that are important in the context of this document include the following:
Any item, piece of equipment, or product system, whether acquired commercially, modified, or customized, that is used to increase, maintain, or improve functional capabilities of individuals with disabilities.
The term "open captions" generally refers to captions that are always rendered with a visual track; they cannot be turned off. The term "closed captions" generally refers to captions that may be turned on and off. The captions requirements of this document assume that the user agent can recognize the captions as such; see the section on applicability for more information.
Note: Other terms that include the word "caption" may have different meanings in this document. For instance, a "table caption" is a title for the table, often positioned graphically above or below the table. In this document, the intended meaning of "caption" will be clear from context.
alt" attribute of the
IMG element in HTML 4.
According to
section 13.2 of the HTML 4 specification ([HTML4]): "User agents must render
alternate text when they cannot support images, they cannot support a certain
image type or when they are configured not to display images.
OBJECT elements in HTML 4.
Section 13.3.1 of the HTML 4 specification ([HTML4]) explains the conditional
rendering rules of (nested)
OBJECT elements. The rules select
among ordered alternatives according to user preferences or error
switch element and test attributes in SMIL 1.0. Sections
4.3 and 4.4, respectively,
of SMIL 1.0
[SMIL] explain the conditional rendering rules of these
switch element and several
attributes for conditional processing.
NOSCRIPT and
NOFRAMES elements in HTML 4
allow the author to provide content under conditions when the user agent does
not support scripts or frames, or the user has turned off support for scripts
or frames.
Specifications vary in how completely they define how and when to render
conditional content. For instance, the HTML 4 specification includes the
rendering conditions for the "
alt" attribute, but not for the
title" attribute. The HTML 4 specification does indicate that the
title" attribute should be available to users through the user
interface ("Values of the title attribute may be rendered by user agents in a
variety of ways...").
Note: The Web Content Accessibility Guidelines 1.0 requires that authors provide text equivalents for non-text content. This is generally done by using the conditional content mechanisms of a markup language. Since conditional content may not be rendered by default, the current document requires the user agent to provide access to unrendered conditional content (checkpoint 2.3 and checkpoint 2.9) as it may have been provided to promote accessibility.
In order to be able to configure and control the user agent, the user needs to be able to "write" as well as "read" values for these parameters. Configuration settings may be stored in a profile. The range and granularity of the changes that can be controlled or configured by the user may depend on limitations of the operating environment or hardware.
Both configuration and control may apply at different "levels": across Web resources (i.e., at the user agent level, or inherited from the operating environment), to the entirety of a Web resource, or to components of a Web resource (e.g., on a per-element basis).
A global configuration is one that applies across elements of the same Web resource, as well as across Web resources. A global configuration may be implemented by more than one setting (e.g., per component of the user agent). For instance, when a user agent consists of a browser that renders HTML and a plug-in that renders SVG, to satisfy the global configuration requirements of this document, the browser may provide one setting and the plug-in another.
User agents may allow users to choose configurations based on various parameters, such as hardware capabilities, natural language, etc.
Note: In this document, the noun "control" refers to a user interface control.
content (which may be conditional content) is either a
null value or an empty string (i.e., one that is zero characters long). For
instance, in HTML,
alt="" sets the value of the "
attribute to the empty string. In some markup languages, an element may have
empty content (e.g., the
HR element in HTML).
Some elements may only be enabled elements for part of a user session. For instance, an element may be disabled by a script as the result of user interaction. Or, an element may only be enabled during a given time period (e.g., during part of a SMIL 1.0 [SMIL] presentation). Or, the user may be viewing content in "read-only" mode, which may disable some elements.
A disabled element is a piece of content that is potentially an enabled element, but is not in the current session. One example of a disabled element is a menu item that is unavailable in the current session; it might be "greyed out" to show that it is disabled. Generally, disabled elements will be interactive elements that are not enabled in the current session. This document distinguishes disabled elements (not currently enabled) from non-interactive elements (never enabled).
For the requirements of this document, user selection does not constitute user interaction with enabled elements. See the definition of content focus.
Note: Enabled and disabled elements come from content; they are not part of the user agent user interface.
Note: The term "active element" is not used in this document since it may suggest several different concepts, including: interactive element, enabled element, an element "in the process of being activated" (which is the meaning of ':active' in CSS2 [CSS2], for example).
Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user. In the context of this document, the equivalent must fulfill essentially the same function for the person with a disability (at least insofar as is feasible, given the nature of the disability and the state of technology), as the primary content does for the person without any disability.
Equivalents include text equivalents (e.g., text equivalents for images, text transcripts for audio tracks, or collated text transcripts for a movie) and non-text equivalents (e.g., a prerecorded audio description of a visual track of a movie, or a sign language video rendition of a written text).
Each markup language defines its own mechanisms for specifying conditional content, and these
mechanisms may be used by authors to provide text equivalents. For instance, in
[HTML4] or SMIL 1.0 [SMIL], authors may use the
alt" attribute to specify a text equivalent for some elements. In
HTML 4, authors may provide equivalents and other conditional content in
attribute values (e.g., the "summary" attribute for the
element), in element content (e.g.,
OBJECT for external content it
NOFRAMES for frame equivalents, and
NOSCRIPT for script equivalents), and in prose. Please consult the Web
Content Accessibility Guidelines 1.0 [WCAG10] and its associated
Techniques document [WCAG10-TECHS] for more
information about equivalents.
Note: The combination of HTML, style sheets, the Document Object Model (DOM), and scripting is commonly referred to as "Dynamic HTML" or DHTML. However, as there is no W3C specification that formally defines DHTML, this document only refers to event handlers and scripts.
Some examples of explicit user requests include when the user selects "New viewport", responds "Yes" to a prompt in the user agent's user interface, configures the user agent to behave in a certain way, or changes the selection or focus with the keyboard or pointing device.
Note: Users make mistakes. For example, a user may inadvertently respond "yes" to a prompt when they meant "no." In this document, this type of mistake is still considered an explicit user request.
User interface mechanisms may resemble content focus, but do not satisfy all of the properties. For example, text editors often implement a "caret" that indicates the current location of text input or editing. The caret may have state and may respond to input device events, but it does not enable users to activate the behaviors associated with enabled elements.
The user interface focus shares the properties of the content focus except that, rather than designating pieces of content, it designates zero or one control of the user agent user interface that has associated behaviors (e.g., radio button, text box, menu, etc.).
On the screen, the content focus may be highlighted using colors, fonts, graphics, magnification, etc. The content focus may also be highlighted when rendered as synthesized speech, for example through changes in speech prosody. The dimensions of the rendered content focus may exceed those of the viewport.
In this document, each viewport is expected to have at most one content focus and at most one user interface focus. This document includes requirements for content focus only, for user interface focus only, and for both. When a requirement refers to both, the term "focus" is used.
When several viewports coexist, at most one viewport's content focus or user interface focus responds to input events; this is called the current focus.
This document includes requirements that the user be able to view the original author-supplied content associated with a placeholder. To satisfy these requirements, the user agent might render the content in place of the placeholder or in a separate viewport (leaving the placeholder as is). A request to view the original content associated with a placeholder is considered an explicit user request to render that content.
This document does not require user agents to include placeholders in the document object. A placeholder that is inserted in the document object should conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. If a placeholder is not part of the document object, it is part of the user interface only (and subject, for example, to checkpoint 1.3).
Some requirements of this document depend on content roles, content relationships, timing relationships, and other information supplied by the author. These requirements only apply when the author has encoded that information in a manner that the user agent can recognize. See the section on conformance in User Agent Accessibility Guidelines 1.0 [UAAG10] for more information about applicability.
In practice, user agents will rely heavily on information that the author has encoded in a markup language or style sheet language. On the other hand, behaviors, style, meaning encoded in a script, and markup in an unfamiliar XML namespace may not be recognized by the user agent as easily or at all.
The term "rendered text" refers to text content that is rendered in a way that communicates information about the characters themselves, whether visually or as synthesized speech.
This document does not require user agents to include repair content in the document object. Repair content inserted in the document object should conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. For more information about repair techniques for Web content and software, refer to "Techniques for Authoring Tool Accessibility Guidelines 1.0" [ATAG10-TECHS].
Information encoded in scripts may be difficult for a user agent to recognize. For instance, a user agent is not expected to recognize that, when executed, a script will calculate a factorial. The user agent will be able to recognize some information in a script by virtue of implementing the scripting language or a known program library (e.g., the user agent is expected to recognize when a script will open a viewport or retrieve a resource from the Web).
On the screen, the selection may be highlighted using colors, fonts, graphics, magnification, etc. The selection may also be highlighted when rendered as synthesized speech, for example through changes in speech prosody. The dimensions of the rendered selection may exceed those of the viewport.
The selection may be used for a variety of purposes: for cut and paste operations, to designate a specific element in a document for the purposes of a query, as an indication of point of regard, etc.
The selection has state, and the user may "set it" (programmatically or through the user interface).
In this document, each viewport is expected to have at most one selection. When several viewports coexist, at most one viewport's selection responds to input events; this is called the current selection.
See the section on the Selection label for information about implementing a selection and conformance.
Note: Some user agents may also implement a selection for designating a range of information in the user agent user interface. The current document only includes requirements for a content selection mechanism.
The expression "sequential navigation" refers to navigation through an ordered set of items (e.g., the enabled elements in a document, a sequence of lines or pages, or a sequence of menu options). Sequential navigation implies that the user cannot skip directly from one member of the set to another, in contrast to direct or structured navigation (see guideline 9 for information about these types of navigation). Users with blindness or some users with a physical disability may navigate content sequentially (e.g., by navigating through links, one by one, in a graphical viewport with or without the aid of an assistive technology). Sequential navigation is important to users who cannot scan rendered content visually for context and also benefits users unfamiliar with content. The increments of sequential navigation may be determined by a number of factors, including element type (e.g., links only), content structure (e.g., navigation from heading to heading), and the current navigation context (e.g., having navigated to a table, allow navigation among the table cells).
Users with serial access to content or who navigate sequentially may require more time to access content than users who use direct or structured navigation.
A text element may consist of both text and non-text data. For instance, a text element may contain markup for style (e.g., font size or color), structure (e.g., heading levels), and other semantics. The essential function of the text element should be retained even if style information happens to be lost in rendering.
A user agent may have to process a text element in order to have access to the text characters. For instance, a text element may consist of markup, it may be encrypted or compressed, or it may include embedded text in a binary format (e.g., JPEG).
"Text content" is content that is composed of one or more text elements. A "text equivalent" (whether in content or the user interface) is an equivalent composed of one or more text elements. Authors generally provide text equivalents for content by using the conditional content mechanisms of a specification.
A "non-text element" is an element (in content or the user interface) that does not have the qualities of a text element. "Non-text content" is composed of one or more non-text elements. A "non-text equivalent" (whether in content or the user interface) is an equivalent composed of one or more non-text elements.
The term "user interface control" refers to a component of the user agent user interface or the content user interface, distinguished where necessary.
Graphical and tactile viewports have two spatial dimensions. A viewport may also have temporal dimensions, for instance when audio, speech, animations, and movies are rendered. When the dimensions (spatial or temporal) of rendered content exceed the dimensions of the viewport, the user agent provides mechanisms such as scroll bars and advance and rewind controls so that the user can access the rendered content "outside" the viewport. Examples include: when the user can only view a portion of a large document through a small graphical viewport, or when audio content has already been played.
When several viewports coexist, only one has the current focus at a given moment. This viewport is highlighted to make it stand out.
User agents may render the same content in a variety of ways; each rendering is called a view. For instance, a user agent may allow users to view an entire document or just a list of the document's headers. These are two different views of the document.
For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Some documents listed below may have been superseded since the publication of this document.
Note: In this document, bracketed labels such as "[HTML4]" link to the corresponding entries in this section. These labels are also identified as references through markup.
There are two recommended ways to refer to the "Techniques for User Agent Accessibility Guidelines 1.0" (and to W3C documents in general):
In almost all cases, references (either by name or by link) should be to a specific version of the document. W3C will make every effort to make this document indefinitely available at its original address in its original form. The top of this document includes the relevant catalog metadata for specific references (including title, publication date, "this version" URI, editors' names, and copyright information).
An XHTML 1.0 [XHTML10] paragraph including a reference to this specific document might be written:
<p> <cite><a href="http://www.w3.org/TR/2002/WD-UAAG10-TECHS-20020821/"> "Techniques for User Agent Accessibility Guidelines 1.0"</a></cite>, I. Jacobs, J. Gunderson, E. Hansen, eds., W3C Working Draft, 21 August 2002. The <a href="http://www.w3.org/TR/UAAG10-TECHS/">latest version</a> of this document is available at http://www.w3.org/TR/UAAG10-TECHS/.</p>
For very general references to this document (where stability of content, anchors, etc., is not required), it may be appropriate to refer to the latest version of this document. In this case, please use the "latest version" URI at the top of this document.
Some of the references in this section become normative if they are used to satisfy the requirements of guideline 6 and guideline 8.
Note: W3C does not guarantee the stability of any of the following references outside of its control. These references are included for convenience. References to products are not endorsements of those products by W3C.
A list of alternative Web browsers (assistive technologies and other user agents designed for accessibility) is maintained at the WAI Web site.
The active participants of the User Agent Accessibility Guidelines Working Group who authored this document were: James Allan (Texas School for the Blind and Visually Impaired), Denis Anson (College Misericordia), Harvey Bingham, Jon Gunderson (Chair of the Working Group, University of Illinois, Urbana-Champaign), Eric Hansen (Educational Testing Service), Ian Jacobs (Team Contact, W3C), Tim Lacy (Microsoft), David Poehlman, and Rich Schwerdtfeger (IBM).
Many thanks to the following people who have contributed through review and past participation in the Working Group: Paul Adelson, Jonny Axelsson, Kitch Barnicle, Olivier Borius, Judy Brewer, Dick Brown, Bryan Campbell, Kevin Carey, Tantek Çelik, Wendy Chisholm, David Clark, Chetz Colwell, Wilson Craig, Nir Dagan, Daniel Dardailler, B. K. Delong, Neal Ewers, Geoff Freed, John Gardner, Al Gilman, Larry Goldberg, Glen Gordon, John Grotting, Markku Hakkinen, Earle Harrison, Chris Hasser, Kathy Hewitt, Philipp Hoschka, Masayasu Ishikawa, Phill Jenkins, Earl Johnson, Jan Kärrman (for help with html2ps), Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Peter Korn, Josh Krieger, Catherine Laws, Aaron Leventhal, Greg Lowney, Susan Lesch, Scott Luebking, William Loughborough, Napoleon Maou, Matt May, Charles McCathieNevile (W3C), Peter Meijer, Karen Moses, Dirk Mueller, Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pederson, Helen Petrie, Michael Pieper, Richard Premack, Mickey Quenzer, Jan Richards, Hans Riesebos, Joe Roeder, Lakespur L. Roca, Gregory Rosmaita, Madeleine Rothberg, Lloyd Rutledge, Liam Quinn, T.V. Raman, Robert Savellis, Constantine Stephanidis, Jim Thatcher, Jutta Treviranus, Claus Thogersen, Steve Tyler, Gregg Vanderheiden, Jaap van Lelieveld, Jon S. von Tetzchner, Willie Walker, Ben Weiss, Evan Wies, Chris Wilson, Henk Wittingen, and Tom Wlodkowski.


text:
|Jepson Flora Project: Jepson Interchange
previous taxon |
next taxon
Jepson Interchange (more information)
©Copyright 1993 by the Regents of the University of California
Perennial (annual), generally twining or trailing
Leaves alternate
Inflorescence: cyme or flowers solitary in axils; pedicels often with 2 bracts
Flower bisexual, radial; sepals 5, ± free, overlapping, persistent, often unequal; corolla generally showy, generally bell-shaped, ± shallowly 5-lobed, generally pleated and twisted in bud; stamens 5, epipetalous; pistil 1, ovary superior, chambers generally 2, ovules generally 2 per chamber, styles 12
Fruit: generally capsule
Seeds 14(6)
Genera in family: 50 genera, 1,000 species: warm temp to tropical; some cultivated as ornamental
Recent taxonomic note: Recently treated to include Cuscutaceae [Angiosperm Phylogeny Group 1998 Ann Missouri Bot Gard 85:531553].
(Family description, key to genera by L.T. Dempster)
Perennial, subshrub from caudex or rhizome, glabrous to tomentose
Stem very short to high-climbing, generally twisting and twining
Leaf generally > 1 cm, linear to reniform, often sagittate to hastate, rarely deeply divided
Inflorescence: peduncle generally 1-flowered; bractlets small and remote from calyx to large and concealing calyx, sometimes lobed
Flower generally showy; corolla glabrous, white or yellow to pink or purple; ovary chamber 1 (septa generally incomplete), stigma lobes 2, generally swollen, cylindric or oblong, ± flattened
Fruit ± spheric, ± inflated
Seeds generally ± 4
Species in genus: ± 25 species: temp, worldwide
Etymology: (Greek: concealing calyx, from bractlets of some)
Reference: [Brummitt 1980 Kew Bull 35(2):327328]
Intergradation common; intermediate forms often difficult to identify. Appears similar to Convolvulus , but anatomy suggests that the 2 genera are not very closely related.
Perennial from rhizome, generally densely tomentose; hairs generally long, brownish
Stem decumbent, 830 cm, not or weakly climbing
Leaf generally < 3 cm at midrib, reniform (basal lobes indistinct) to distinctly lobed; margin generally wavy
Inflorescence: peduncle < 6 cm, sometimes > subtending leaf; bractlets 717 mm, 214 mm wide, ± linear to widely ovate, entire, attached just below calyx, partly to entirely concealing it
Flower: sepals 813 mm; corolla 2555 mm, white
Ecology: Open grassy or rocky places or in open oak/pine woods, often on serpentine
Elevation: < 600 m.
Bioregional distribution: North Coast Ranges, San Francisco Bay Area, South Coast Ranges
Synonyms: Convolvulus c. Greene; C. malacophyllus subsp. c. (Greene) Abrams

subset: commoncrawl


text: Massachusetts based artist Sydney Hardin's work questions the relationship between the female gender and the media and asks the viewer why over simplified representations of female sexuality are aimed at male and female consumers alike. I am really enjoying her work, not to mention the name of her website! ( http://www.giantvagina.com/ )


text:
2014: Appeared in all 12 games for the fourth-straight year as the long snapper on punts and extra points/field goals ... Registered a tackle in the win against FIU.
2013: Played in all 12 games as the long snapper on punts and PAT's and field goals ... Handled all snaps flawlessly for the third-straight year ... Recorded a tackle in the win over The Citadel.
2012: College Sporting News Fabulous 50 All-American ... Appeared in all 13 games for the second-straight year handling all the long snapping duties for punts and field goals/extra points ... Recorded two tackles on the year ... Had tackles against Hampton and Coastal Carolina.
2011: Appeared in all 13 games as the Monarchs' long snapper.
HIGH SCHOOL: Third Team All-Monmouth County and All-Conference as a senior ... Started long snapping as a freshman at Middletown South ... Averaged .70 seconds on long snaps ... Also saw time at center and on the defensive line ... Helped Middletown South to a 39-6 during his career, three state runner-up titles, and the 2009 Colonial Division Championship ... Chris Rubio long snapping student since 2009, ranking as high as 13th in the country ... Played for Middletown South head coach Steve Antonucci.
PERSONAL: Born September 9, 1992 ... Son of Rick and Maureen Lovato ... Has two sisters, Michelle and Jacqueline ... Majoring in exercise science.


text:
TUESDAY, Jan. 31, 2012 (HealthDay News) -- When children are sick, family participation is central to their treatment, says a new policy statement from the American Academy of Pediatrics, which calls for patients, their parents and pediatricians to become partners at every level of care.
In the hospital, parents should be encouraged to stay with their child, sit in on physician "rounds," and accompany the youngster during medical procedures, the statement says. Pediatricians should also offer parents support, respect their preferences about care and communicate openly with children and teenagers about their condition.
"It's incorporating where the family stands, its belief systems, to help in making decisions," said Dr. Jerrold Eichner, co-author of the statement and a pediatric pulmonologist and past chair of the AAP's Committee on Hospital Care. "It's a gradual movement, going on for decades."
The statement, published online Jan. 30 and in the February print issue of Pediatrics, was met with praise from a family health advocate.
"I'm actually very appreciative of the statement," said Karen Herzog, co-founder of Sophia's Garden Foundation, an organization centered on helping families with children with life-threatening conditions.
"It's imperative that professional organizations like the AAP and the American Medical Association take a firm stand on patient- and family-centered care," she said. "We need to work in partnership to improve our health outcomes together.
Herzog's daughter died of a rare illness when she was 4 years old. Her family took ownership of her care to an uncommon degree.
"I actually recruited practitioners to work on her care team, both local and internationally. We wanted to assemble a team that incorporated many different disciplines and cultural values and different medical perspectives," Herzog said.
One priority was making sure that care was about Sophia's needs rather than fitting into standard practice.
"We were with hospice for two and a half years," Herzog said. "Usually they just stay when a child has six months or fewer to live. At that time, we chose to have curative care [as well]. We wanted to be able to take our child to the doctor or hospital at any point in time that we chose, rather than when it was approved by hospice."
AAP's new policy supports this kind of flexibility.
It encourages "honoring patient and family experiences and incorporating them with patient and family preferences into the planning and delivery of health care," and tailoring services to "family-patient needs, beliefs, cultural values."
Cultural sensitivity is important, Eichner said. "If a patient or family has a cultural or personal aversion, they may not tell you; they just won't comply with the treatment," he said.
The statement lays out specifics for family inclusion. "In hospitals, conducting attending physician rounds [patient presentation and discussions] in the patients' rooms with nursing staff and the family present should be standard practice," it said, and parents should have the option to be present during medical procedures.
Herzog said she wished the policy placed more emphasis on pediatric care in the home, and on families of children with special needs.
Also missing is a strong recognition of health information technology, Herzog said. "The policy talks about the flow of information. [But] there's nothing about electronic medical records," she explained.
She also wants "openness to practitioners when patients bring in information that they've found on the Internet."
The statement does address peer-to-peer communication, and social media and the Internet is part of that, Eichner said. For his patients with cystic fibrosis, diabetes and other chronic conditions, "[the web] is especially helpful for older kids."
Collaboration includes involving patients and families in task forces, advisory councils and committees to improve patient safety, and as leaders of peer-support programs, the statement said.
Getting patients and families onboard helps doctors as well, Eichner said. "It's a lot easier to deal with patients when they feel you're listening," he added. "When they know that you'll be honest with them and give them the complete story on what's going on with their child."
A "sea change" is happening in health care, Herzog said.
One sign is "coming out with a stance like this, something that pediatricians can adhere to, when they're rated by their peers," she said. "They can be evaluated by AAP or other organizations. If there's any kind of problem, did the physicians adhere to these standards? They're like minimally acceptable standards."
More information
Visit the Institute for Patient- and Family-Centered Care to learn more about the concept and practice.