WAI Page Author Guidelines
W3C Working Draft
- This version:
- Latest version:
- Latest public version:
- Previous version:
- Related documents:
- Techniques for WAI Page Author Guidelines
- A checklist of checkpoints
- A checklist of just Priority 1 checkpoints
- Wendy Chisholm <firstname.lastname@example.org>
Gregg Vanderheiden <email@example.com>
Ian Jacobs <firstname.lastname@example.org>
This document is a list of guidelines that page authors should follow in order to make
their pages more accessible for people with disabilities as well as
more useful to other users, new page viewing technologies (mobile
and voice), and electronic agents such as indexing robots. Tools
that generate documents in HTML (authoring tools, file conversion
packages, or other products) should make it easy for authors to
produce documents that follow these guidelines. This document is
part of a series of accessibility documents published by the Web Accessibility Initiative.
Accessibility does not mean minimal page design, it means
thoughtful page design. These guidelines outline procedures for
authors, particularly those using multimedia content, to ensure
that the content and functions provided by those elements are
available to all users. In general, authors should not be
discouraged from using multimedia, but rather should use it in a
manner which ensures that the material they publish is accessible
to the widest possible audience.
In this document references are made to some technologies that
are not yet widely supported or not supported consistently in
current user agents (browsers), such as new features introduced in
HTML 4.0. Since this document is "frozen" we can not list which
features are supported as of "today." Therefore, the WAI Page Authoring
Techniques document links to information about feature support of
This is a W3C Working Draft for review by W3C members and other
interested parties. 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 members of the WAI GL Working Group.
This document has been produced as part of the W3C WAI Activity, and is intended as a
draft of a Proposed Recommendation for authoring accessible Web
pages. The goal of the WAI-GL
working group is discussed in our charter.
This document is available in the following formats:
In case of a discrepancy between the various formats of the
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19981218/wai-pageauth.html is considered the definitive
Please send detailed comments on this document to email@example.com. Public comments
about the WAI author guidelines can also be sent to this
- A. Transform Gracefully
- A.1 Provide alternative text for all images, applets, and image maps.
- A.2 Provide descriptions for important graphics, scripts, or applets if they are not fully described through alternative text or in the document's content.
- A.3 Provide textual equivalents (captions) for all audio information.
- A.4 Provide verbal descriptions of moving visual information in both auditory and text form (for movies, animations, etc.).
- A.5 Ensure that text and graphics are perceivable and understandable when viewed without color.
- A.6 Indicate structure with structural elements, and control presentation with presentation elements and style sheets.
- A.7 Provide supplemental information needed to pronounce or interpret abbreviated or foreign text.
- A.8 Ensure that tables have necessary markup to be properly restructured or presented by accessible browsers and other user agents.
- A.9 Ensure that pages using newer technologies will transform gracefully into an accessible form if the technology is not supported or is turned off.
- A.10 Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or frozen.
- A.11 Elements that contain their own user interface should have accessibility built in.
- A.12 Use features that enable activation of page elements via input devices other than a pointing device (e.g., via keyboard, voice, etc.).
- A.13 Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.
- A.14 Wherever possible use a W3C technology in accordance with guidelines on its proper use. Where this is either not possible, or results in material that does not transform gracefully you must provide an alternative version of the content that is accessible.
- B. Orientation, Navigation, and Comprehension
- C. Appendix - Testing
- D. Appendix - Definitions
- [PRIORITY 1]
- This checkpoint must be addressed by an author,
or one or more groups of users will find it impossible to access
information in the document. Satisfying this checkpoint is a basic
requirement for some groups to be able to use Web documents.
- [PRIORITY 2]
- This checkpoint should be addressed by an
author, or one or more groups of users will find it difficult to
access information in the document. Satisfying this checkpoint
will significantly improve access to Web documents.
- [PRIORITY 3]
- This checkpoint may be addressed by an author to
make it easier for one or more groups of users to access
information in the document. Satisfying this checkpoint will
improve access to Web documents.
Make sure pages transform gracefully across users,
technologies, and situations
To "transform gracefully" means that a page remains usable
despite user, technological, or situational constraints. User
constraints require that the information is presented so that they
are able to perceive or interact with it due to a physical or
sensory limitation on their part. However, this limitation might be
caused by a situation. The user who is blind has the same
limitations as someone whose eyes are busy while they drive a car.
Technological constraints are defined by the device a person is
using to access a document. A small screen on a PDA creates a
similar usability constraint to a person with low-vision who has
magnified their screen such that they are looking at the
information as if through a very small screen.
Since HTML, XML, and other W3C technologies are designed with
the flexibility to create documents that may be formatted in
various ways on a variety of platforms, by virtue they support
accessible design. Non-accessible pages are a result of giving up
this flexibility. Creating pages that transform gracefully is not
more costly, but requires a different design approach that also
makes pages compatible with emerging mobile technologies. The
following section A guidelines address the issue of creating pages
that transform gracefully. They all stem from the following general
Always separate the content on your site
(what you say), and the way you choose to structure that content
(how you organize it), from the way the content and structure are
presented (how you want people to "see" it or perceive
it). (If the content is sensory specific, such as
audio or video, make it available in a form that allows
presentation in other senses.)
Documents that transform gracefully are:
- Able to be perceived entirely visually and entirely
through auditory means. This does not mean creating an
entire auditory version of your site. Screen readers will
be able to speak all information on a page as long as it is
available in text.
- Operable on various types of hardware including devices
without mice, with small, low resolution, or black and white
screens, with only voice or text output, without screens,
etc. Due to the inherent flexibility of the design of W3C
technologies your pages will be cross platform if you follow the
basic principles outlined in this document.
Guidelines A.1 - A.12 address these issues.
This includes images used as submit buttons, bullets in lists,
and all of the links within an image map as well as invisible
images used to layout a page. Alternative text does
not describe the visual appearance of an image, applet, or image
map. Rather, it is used to represent the function that the image,
applet, or image map performs whether it be decorative,
informative, or for purposes of layout. If alternative text is not
provided, users who are blind, have low
vision, or any user who cannot or has chosen not
to view graphics will not know the purpose of the visual
components on the page. Since "bare" ASCII
art (characters that form images) does not allow alt-text, it
must be marked up specially for this purpose.
- Provide alternative text for all images (e.g., in HTML, via the "alt" attribute of the IMG and INPUT elements, or via "title" or within the content of OBJECT). Note. This includes images used as image maps, spacers, bullets in lists, graphical buttons and links. [Priority 1]
- Provide alternative text for all applets and other programmatic objects (e.g., in HTML, via the "alt" attribute or within the content of APPLET, or via the "title" attribute or within the content of OBJECT). (See also A.11) [Priority 1]
- For all image map links, provide alternative text for each link (e.g., via the "alt" attribute of HTML AREA element). [Priority 1]
- For all image map links, provide redundant textual links. [Priority 2] if client-side image maps are used, [Priority 1] for server-side.
- Do not use an image map to create a set of buttons in a form. Instead, use separate buttons or images (accompanied by alternative text). [Priority 2]
- Replace ASCII art with an image and alternative text. [Priority 1] or [Priority 2] depending on the importance of the information (e.g., an important chart). Note. If the description of (important) ASCII art is long, provide a description in addition to alternative text. (See also A.2)
Otherwise, important information
presented graphically (charts, billboards, diagrams) will not be
perceivable to people with blindness, some people
with low vision, and users who have chosen
not to view graphics, scripts, or applets or whose
browser does not support scripts or applets.
Note. Long descriptions serve a
different purpose than alternative text: a long description
provides a description of the visual information of the
image whereas alternative text acts as a substitute for the
function of the image.
- Provide a long description of all graphics, scripts, or applets that convey important information (e.g., in HTML, via "longdesc" on IMG, with a d-link (or an invisible d-link), or as content of OBJECT). [Priority 1]
If the audio is associated with a visual presentation (movie or
animation), synchronize the textual equivalents
with the visual presentation. Otherwise, users who are
deaf, or hard of hearing, or
any user who cannot or has chosen not to hear
sound cannot perceive the information presented through
speech, sound effects, music, etc.
- For stand-alone audio files, provide a textual transcript of all words spoken or sung as well as all significant sounds. [Priority 1]
- For audio associated with video, provide a textual transcript (of dialog and sounds) synchronized with the video (e.g., captions). [Priority 1]
- Where sounds are played automatically, provide visual notification and transcripts. [Priority 1] or [Priority 2] depending on the importance of the sound.
If the visual presentation is associated with an auditory
presentation (e.g., for a movie), synchronize the audio
version of the descriptions with the existing auditory
presentation and collate
the text version of the descriptions with the text transcript
(captions) of the primary audio track. Otherwise, if
actions, body language, or other visual cues present information
that is not expressed through auditory means as well (through
dialogue, sound effects, etc.), users who cannot
see (or look at) the page will not be able to perceive it.
The collated text version allows access to the information by
devices that do not play movies and by people who are
- For short animations such as animated "gifs" images, provide alternative text (See also A.1) and a long description (See also A.2) if needed. [Priority 1]
- For movies, provide auditory descriptions that are synchronized with the original audio. [Priority 1]
- Provide text version of the auditory description that is collated with the text transcript (captions) of the primary audio track. [Priority 2]
Otherwise, if color is used to convey information, users
who cannot differentiate between certain colors (and
users with devices that have non-color or non-visual
displays) will not receive the information.
When foreground and background colors are too close to the same
hue, they may not provide sufficient contrast when viewed using
monochrome displays or by people with
different types of color deficiencies.
- Don't use color to convey information unless the information is also clear from the markup and/or text. [Priority 1]
- Use foreground and background color combinations that provide sufficient contrast when viewed by someone with color deficits or when viewed on a black and white screen. [Priority 1]
elements and attributes are used to create presentation
effects, user agents that allow users to navigate through
the structure will be unable to do so properly. Such
practices also make it difficult to render the page on other media
and devices. For instance, in HTML, don't use H1 to create large,
bold face text unless that text is actually a top-level
- Nest headings properly (e.g., in HTML, H1 - H6). [Priority 2]
- Encode list structure and list items properly (e.g., in HTML: UL, OL, DL, LI). [Priority 2]
- Mark up quotations (e.g., with the Q and BLOCKQUOTE elements in HTML). Do not use quotation markup for formatting effects such as indentation. [Priority 2]
- Use style sheets to control layout and presentation wherever possible as soon as a majority of browsers in use support them well (See also A.9). Until then, simple tables (to control layout) and bitmap text with alt-text (for special text effects) may be used, with alternative pages used as necessary to ensure that the information on the page is accessible (See also A.14). [Priority 2]
- Use relative sizing and positioning (e.g., percent values) rather than absolute (e.g., pixel or point values). [Priority 2]
Unless changes between multiple languages on the same page are
identified, and expansions for abbreviations and acronyms are
provided, they may be indecipherable when spoken
or brailled. This also means that the predominant
language on the page must be identified. Supplemental information
also helps search engines find key words and identify documents in
a desired language.
- Clearly identify changes in the language of text (e.g., the HTML "lang" attribute). [Priority 2]
- Specify the expansion of abbreviations and acronyms (e.g., with the "title" attribute of the HTML ABBR or ACRONYM elements). [Priority 2]
Many user agents restructure tables to present them. Without
appropriate markup, the tables will not make sense when
restructured. Tables also present special problems to users
of screen readers.
These guidelines benefit users that are accessing the
table through auditory means (e.g., an Automobile PC which operates
by speech input and output) or viewing only a
portion of the page at a time (e.g., users with blindness or low
vision using speech or a braille
display, or other users of devices with small displays,
- If a table is used for layout, do not use any structural markup for the purpose of visual formatting. Should this be Pri 1? For example, in HTML do not use the table header (TH) element to cause the contents of a cell to be displayed centered and in bold. Other attributes of a table, such as a caption describing the layout purpose and content of columns is valuable, particularly if some cells become navbars, frames, images, imagemaps, or lists of links. [Priority 1]
- Identify headers for rows and columns (e.g., the HTML TD and TH elements). [Priority 2]
- Where tables have structural divisions beyond those implicit in the rows and columns, use markup to identify those divisions (e.g., in HTML, THEAD, TFOOT, TBODY, COLGROUP, the "axis" and "scope" attributes, etc.). [Priority 2]
- Provide summaries for tables (e.g., via the "summary" attribute on HTML TABLE elements). [Priority 3]
- Provide abbreviations for header labels (e.g., in HTML, the "abbr" attribute on TH). [Priority 3]
The ever-changing landscape of technologies available on the
Internet is influenced by W3C Recommendations (such as HTML) and
proprietary formats (such as ShockWave, and PDF). However, with
each new release of Recommendations, browsers, or plug-ins, new
features are added that may not be completely backwards compatible. For example, HTML
4.0 added the ability to attach style sheets to a page and to embed
scripts and applets into a page. Older browsers
ignore new features and some users configure their browser
not to make use of new features. These users often see
nothing more than a blank page or an unusable page when new
features do not transform gracefully.
- For frames, provide a fallback page for pages that contain frames (e.g., by using NOFRAMES in HTML at the end of each frameset). [Priority 1]
- For frames, ensure that the source of each frame is a markup file, such as HTML. [Priority 1]
- For scripts that present critical information or functions, provide an alternative, equivalent presentation or mechanism (e.g., by using NOSCRIPT in HTML, or a server-side script). [Priority 1]
- For pages that use style sheets, ensure that the contents of each page are ordered and structured so that they may read in the intended order even when the style sheet is not used. [Priority 1]
- For applets and programmatic objects,
at a minimum, follow the techniques for
alternative text and
long descriptions, where
- For applets and programmatic objects, when possible provide an alternative function or presentation in a format other than an applet. For example, a canned "mpeg" movie of a physics simulation (written in Java) or a single frame of the animation saved as a "gif" image. [Priority 2]
See also the technique on alternative pages.
This is particularly important for objects that contain
text and does not apply to instant
redirection. Some people with
cognitive limitations or visual
disabilities are unable to read moving text quickly enough
or at all. Movement can also cause such a distraction that the rest
of the page becomes unreadable for people with cognitive
disabilities. Screen readers
are unable to read moving text. People with physical
disabilities might not be able to move quickly or
accurately enough to interact with moving objects. People with
photosensitive epilepsy can have seizures triggered by
flickering or flashing in the 4 to 59 flashes per second (Hertz)
range with a peak sensitivity at 20 flashes per second as well as
quick changes from dark to light (like strobe lights).
- For auto-refreshing or timed response pages, provide a second copy of the page where refresh only happens after a link has been selected (until user agents provide this ability themselves). [Priority 1]
- Avoid any blinking or updating of the screen that causes flicker. [Priority 1]
- Movement should be avoided when possible, but if it must be used, provide a mechanism to allow users to freeze motion or updates in applets and scripts or use style sheets and scripting to create movement. (See also A.11) [Priority 2]
Note 1. The BLINK and MARQUEE elements,
commonly used in HTML pages, are not defined in any W3C HTML
specification and should not be used. (See also A.14)
Note 2. (See also A.4)
The accessibility of objects with their own interface is
independent of the accessibility of the user agent. Accessibility
must therefore be built into the objects or an alternative must be
provided (See also A.12)
- Where possible, make programmatic elements, such as scripts and applets, directly accessible. (See also A.9). [Priority 1] if information or functionality is important, and not presented elsewhere, otherwise [Priority 2].
Someone who is using the page without sight, with voice
input, or with a keyboard (or input device other than a
pointing device, e.g., a mouse or
braille display) will have a difficult time navigating a page
if operation requires a pointing device. If a page is
usable via a
keyboard, it is more likely that it should also be operable via
speech input, or a command line interface. Access to
image maps is impossible for these users if alternatives are not
- For image maps, provide alternative text for links. (See also A.1) [Priority 1]
- If possible, ensure that all elements that have their own interface are keyboard operable. (See also A.12) [Priority 2]
- Create a logical tab order through links, form controls, and objects (e.g., in HTML, via the "tabindex" attribute or through logical page design). [Priority 3]
- Provide keyboard shortcuts to links, including those in client-side image maps, form controls, and groups of form controls (e.g., in HTML, via the "accesskey" attribute). [Priority 3]
Older browsers are unable to "Tab" to edit
boxes, text areas and lists of consecutive links, making it
difficult to impossible for users to access them. Users not
operating in a graphical environment are disoriented by
being transferred to a new window without warning.
Checkpoints until most users are able to secure newer technologies that
address these issues:
- Do not use pop-up windows, new windows, or change active window unless the user is aware that this is happening. [Priority 2]
- Include default, place-holding characters in edit boxes and text areas (e.g., TEXTAREA and INPUT in HTML). [Priority 3]
- Include non-link, printable characters (surrounded by spaces) between links that occur consecutively. [Priority 3]
- For all form controls with implicitly associated labels, ensure that the label is properly positioned. The label must immediately precede its control on the same line (allowing more than one control/label per line) or be on the line before the control (with only one label and one control per line). [Priority 2]
- Until user agents and screen readers are able to handle text presented side-by-side, all tables that lay out text in parallel, word-wrapped columns require a linear text alternative (on the current page or some other). [Priority 2]
Many non-HTML technologies (e.g., PDF, Shockwave, and other
non-W3C data formats) used to encode information require either
plug-ins or stand-alone applications that often create pages that
cannot be viewed or navigated using standard Web access tools.
Also, W3C technologies may be used in ways that do not transform
gracefully (e.g., because the visual components are too complex, or
because assistive technologies or user agents (browsers) are
lacking a specific feature). By avoiding non-standard
features (elements, attributes, properties, etc. only supported by
a specific browser type) and ensuring that all technologies
transform gracefully, your pages will be accessible to more people
using a wider variety of hardware and software.
Note. Not all PDF pages are accessible or
readable after being run through a PDF translator. Individually
test each page for readability after the translation process. If a
page does not automatically translate, revise the page until its
PDF representation converts appropriately through the
publicly-available converter(s) or prepare and post an HTML or
plain text equivalent.
- If W3C technologies are used, use the latest W3C specification whenever possible. [Priority 2]
- If W3C technologies are used, avoid deprecated language features whenever possible. [Priority 2]
- If, after all of your best efforts, you can not avoid using a non-W3C technology or any W3C technology in an accessible way then you MUST provide a link to an alternative page that:
- uses W3C technologies,
- is accessible,
- has equivalent information,
- is updated as often as the inaccessible (original) page
Note. Alternative pages should be used sparingly since authors tend to neglect updating the alternative page as often as the original page. An out-of-date page may be as frustrating as one that is inaccessible since, in both cases, the information presented on the original page is not available. Automatically generating alternative pages can make it easier to keep up with updates. However, authors must be careful to ensure that generated pages always make sense and that users be able to navigate a site by following links on primary pages, alternative pages, or both.. Before resorting to an alternative page you may want to reconsider the design of the original page. A page that is too elaborate may deter a larger audience than you might expect.
- When linking to resources that are not W3C technologies, indicate what type of resource you are linking to. For example, to link to a PDF file from an HTML document, set the "type" attribute to "application/pdf" on the A element. [Priority 3]
Maximize usability by providing context and orientation
information and simplifying presentations of information.
To provide context and orientation information means that
additional information is provided to help users gain an
understanding of the "big picture" presented by a page, table,
frame, or form. Oftentimes users are limited to viewing only a
portion of a page, either because they are accessing the page one
word at a time (speech synthesis or
braille display), or one section at a time (small display, or a
Complex relationships between elements on a page may also be
difficult for people with cognitive disabilities
to interpret. Grouping and providing contextual information about
the relationships between elements can be useful for all
- Name each frame so that users can keep track of frames by name (e.g., via the "title" attribute on HTML FRAME elements). [Priority 1]
- Describe the purpose of frames and how frames relate to each other if it is not obvious by frame names alone. (e.g., in HTML, use "longdesc". Until "longdesc" is widely supported, also use a d-link or invisible d-link). [Priority 2]
- Group form controls (e.g., in HTML use the FIELDSET and LEGEND elements). [Priority 2] for radio buttons and checkboxes, [Priority 3] for other controls.
- Associate labels explicitly with their controls (e.g., in HTML use LABEL and its "for" attribute). [Priority 2]
- Create a hierarchy of long lists of choices (e.g., with the HTML OPTGROUP element). [Priority 2]
Through good design, increase the chance that a person can
easily find what they are looking for and can easily navigate
throughout the site. A clear navigation structure will not only
benefit people with cognitive disabilities, but
everyone that visits your site.
To decrease the amount of sifting readers perform to find important information, place distinguishing
information at the beginning of headings, paragraphs, lists, etc.
This is commonly referred to as "front-loading" and is especially
helpful for people accessing information
Consistent page layouts, common icons, and easy to understand
language will benefit everyone in general, but especially people
with cognitive disabilities, people whose
native language is not the same as yours, or
people who have difficulty reading. However, ensure that
images have alternative text for people who are
blind, have low vision, or any
user who cannot or has chosen not to view graphics
(See also A.1)
- Wherever possible, make link phrases as terse as possible yet as meaningful as possible when read on their own or in succession . Avoid non-meaningful phrases, such as "click here." [Priority 2]
- Use a clear, consistent navigation structure. [Priority 3]
- Offer navigation bars for easy access to the navigation structure. [Priority 3]
- Offer a site map. [Priority 3]
- Provide a description of the general layout of the site, the access features used, and how to use them. [Priority 3]
- Offer different types of searches for different skill levels and preferences. [Priority 3]
- Place distinguishing information at the beginning of headings, paragraphs, lists, etc. [Priority 3]
- Facilitate off-line browsing by creating a single downloadable file for documents that exist as a series of separate pages (e.g., by using the HTML LINK element, or creating a "zip" archive). [Priority 3]
- Group related links, such as links used to create a navigation bar, and attach a meaningful title on the element creating the group (e.g., in HTML use "title" on FRAME, DIV, SPAN, etc. Use class="nav" on elements creating navigation groups). [Priority 3]
- Provide a link at the beginning of a group of related links to bypass the group. [Priority 3]
- Use the simplest and most straightforward language that is possible for the content of your site. [Priority 2]
- Use icons or graphics (with alternative text) where they facilitate comprehension of the page. [Priority 3]
- Create a consistent style of presentation between pages. [Priority 3]
It is important to test your site with various types of
browsers, older versions of current browsers, and services that
emulate browsers. Testing your site with a variety of browsers and
other services will allow you to gain firsthand experience of some
of the issues people deal with. Adjustments to your design based on
the results of tests will increase the likelihood that your site
will be usable by a wide range of people and technologies.
- Use an automated
accessibility and browser validation tool.
- Validate your
- Validate your
- Use a text-only browser
multiple graphic browsers, with:
- sounds and graphics loaded,
- graphics not loaded,
- sounds not loaded,
- no mouse,
- frames, scripts, style sheets, and applets not loaded
- Use a several browsers,
old and new.
It may also be helpful to test a site
with a self-voicing
browser, a screen reader, magnification software, a small display,
- Use a spell
checker. A person reading a page with a speech synthesizer may
not be able to decipher the synthesizer's best guess for a word
with a spelling error.
- A program inserted into a Web page.
- ASCII art
- ASCII art refers to text characters and symbols that are
combined to create an image. For example
";-)" is the smiley emoticon and the following drawing
represents a cow.
/ | ||
- Something that has been designed to work with earlier versions
of a language, program, etc.
- Braille uses six raised dots in different patterns to represent
letters and numbers to be read by people who are blind with their
The word "Accessible" in braille.
- A braille display, commonly referred to as a "dynamic braille
display," raises or lowers dot patterns on command from an
electronic device, usually a computer. The result is a line of
braille that can change from moment to moment. Dynamic braille
displays range in size from one cell (six or eight dots) to an
eighty cell line. Displays with twelve to twenty cells per line are
most common, due to cost.
- Webster's dictionary defines collate as, "To gather and place
in order, as the sheets of a book for binding." When referring to
transcripts, the text version of the descriptions and the text
transcript (captions) of the primary audio track are combined into
a single document to read like a script of the movie. In other
words, the two documents are not combined but flows as a single
- A graphical presentation.
- Image map
- An image that has been divided into regions; clicking in a
region causes an action to occur.
- Something is important if understanding it in detail is
necessary for the overall understanding of a document.
- A page is loaded but immediately replaced by another due to
meta information in the transient document.
- Page authors
- Those who are creating Web pages.
- A software program that magnifies a portion of the screen, so
that it can be more easily viewed. Used primarily by individuals
with low vision.
- Screen reader
- A software program that reads the contents of the screen aloud
to a user. Used primarily by individuals who are blind, screen
readers can usually only read text that is printed, not painted, to