Enabling
users
of
assistive
technologies
to
find
their
way
through
Web
content
requires
embedding
semantic
metadata
about
Web
document
structural
divisions.
This
is
particularly
important
for
structural
divisions
of
long-form
documents
and
goes
along
with
embedding
semantic
metadata
about
Web-application
widgets
and
behaviors
for
assistive
technologies.
This
specification
defines
a
set
of
WAI-ARIA
roles
specific
to
helping
users
of
assistive
technologies
navigate
through
such
long-form
documents.
This
document
is
part
of
the
WAI-ARIA
suite
described
in
the
WAI-ARIA
Overview
.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
https://www.w3.org/TR/.
GitHub
Issues
are
preferred
for
discussion
of
this
specification.
Alternatively,
you
can
send
comments
to
our
mailing
list.
Please
send
them
to
[email protected]
(
archives
).
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
WAI-ARIA
is
a
technical
specification
that
defines
a
common
host
language
semantic
accessibility
API
and
framework
that
enables
web
browsers
to
map
the
accessibility
semantics
in
web
content
to
platform-specific
accessibility
APIs.
This
enables
web
content
to
be
interoperable
with
platform
assistive
technologies
similar
to
native
platform
applications
without
platform
dependencies.
This
specification
is
a
modular
extension
of
WAI-ARIA
designed
for
the
digital
publishing
industry.
The
goals
of
this
specification
include:
Expanding
[
WAI-ARIA
]
to
produce
structural
semantic
extensions
to
accommodate
the
digital
publishing
industry.
Align
with
a
new
governance
model
for
modularization
and
extensions
to
WAI-ARIA
.
Provide
structural
semantics
extensions
that
will
support
both
assistive
technologies
and
enable
semantic
navigation,
styling
and
interactive
features
used
by
readers.
For
a
more
detailed
explanation
of
WAI-ARIA
please
refer
to
the
WAI-ARIA
Introduction
and
how
it
applies
to
Rich
Internet
Application
Accessibility.
1.1
Target
Audience
This
specification
defines
a
module
of
WAI-ARIA
for
digital
publishing,
including
roles
,
states
,
properties
and
values.
It
impacts
several
audiences:
User
agents
that
process
content
containing
WAI-ARIA
and
Digital
Publishing
WAI-ARIA
features;
Authoring
tools
that
help
authors
create
conforming
digital
publications;
and
Conformance
checkers,
that
verify
appropriate
use
of
WAI-ARIA
and
this
Digital
Publishing
WAI-ARIA
module.
Each
conformance
requirement
indicates
the
audience
to
which
it
applies.
Although
this
specification
is
applicable
to
the
above
audiences,
it
is
not
specifically
targeted
to,
nor
is
it
intended
to
be
the
sole
source
of
information
for,
any
of
these
audiences.
In
the
future,
additional
documents
will
be
created
to
assist
authors
in
applying
these
WAI-ARIA
semantics
for
the
publishing
industry
and
to
define
how
the
information
in
this
document
is
mapped
to
platform
accessibility
APIs.
1.2
User
Agent
Support
This
module
builds
on
the
general
User
Agent
support
principles
defined
in
[
WAI-ARIA
]
by
also
providing
the
ability
for
user
agents
to
enhance
the
general
user
interface
presented
to
readers.
1.3
Co-Evolution
of
WAI-ARIA
and
Host
Languages
The
Digital
Publishing
WAI-ARIA
module
follows
the
model
for
co-evolution
of
WAI-ARIA
and
host
languages
defined
in
[
WAI-ARIA
].
It
is
intended
to
augment
semantics
in
supporting
languages
like
[
HTML5
],
[
SVG2
]
and
EPUB,
or
to
be
used
as
an
accessibility
enhancement
technology
in
other
markup-based
languages
that
do
not
explicitly
include
support
for
ARIA.
It
clarifies
semantics
to
assistive
technologies
when
authors
create
new
types
of
objects,
via
style
and
script,
that
are
not
yet
directly
supported
by
the
language
of
the
page,
because
the
invention
of
new
types
of
objects
is
faster
than
standardized
support
for
them
appears
in
web
languages.
It
is
not
appropriate
to
create
objects
with
style
and
script
when
the
host
language
provides
a
semantic
element
for
that
type
of
objects.
While
WAI-ARIA
can
improve
the
accessibility
of
these
objects,
accessibility
is
best
provided
by
allowing
the
user
agent
to
handle
the
object
natively.
For
example,
it
is
not
better
to
use
a
heading
role
on
a
div
element
than
it
is
to
use
a
native
heading
element,
such
as
an
h1
.
It
is
expected
that,
over
time,
host
languages
will
evolve
to
provide
semantics
for
objects
that
currently
can
only
be
declared
with
this
specification.
This
is
natural
and
desirable,
as
one
goal
of
WAI-ARIA
is
to
help
stimulate
the
emergence
of
more
semantic
and
accessible
markup.
When
native
semantics
for
a
given
feature
become
available,
it
is
appropriate
for
authors
to
use
the
native
feature
and
stop
using
this
module
for
that
feature.
Legacy
content
may
continue
to
use
the
Digital
Publishing
WAI-ARIA
module,
however,
so
the
need
for
user
agents
to
support
it
remains.
While
specific
features
of
this
module
may
lose
importance
over
time,
the
general
possibility
of
the
Digital
Publishing
WAI-ARIA
module
to
add
semantics
to
web
pages
or
open
web
based
standards,
such
as
EPUB,
is
expected
to
be
a
persistent
need.
Host
languages
may
not
implement
all
the
semantics
this
module
provides,
and
various
host
languages
may
implement
different
subsets
of
the
features.
New
types
of
objects
are
continually
being
developed,
and
one
goal
of
this
specification
is
to
provide
a
way
to
make
such
objects
accessible,
because
authoring
practices
often
advance
faster
than
host
language
standards.
In
this
way,
this
module
and
host
languages
both
evolve
together
but
at
different
rates.
Some
host
languages
exist
to
create
semantics
for
features
other
than
the
user
interface.
For
example,
SVG
expresses
the
semantics
behind
production
of
graphical
objects,
not
of
user
interface
components
that
those
objects
may
represent.
Host
languages
such
as
these
might,
by
design,
not
provide
native
semantics
that
map
to
this
specification's
features.
In
these
cases,
the
Digital
Publishing
WAI-ARIA
module
could
be
adopted
as
a
long-term
approach
to
add
semantic
information
to
these
host
languages.
1.4
Authoring
Practices
1.4.1
Authoring
Tools
Many
of
the
requirements
in
the
definitions
of
the
WAI-ARIA
and
Digital
Publishing
WAI-ARIA
roles
,
states
and
properties
can
be
checked
automatically
during
the
development
process,
similar
to
other
quality
control
processes
used
for
validating
code.
To
assist
authors
who
are
creating
digital
publications,
such
as
EPUB,
can
compare
the
semantic
structure
of
Digital
Publishing
WAI-ARIA
roles
from
the
DOM
to
that
defined
in
this
specification
and
notify
the
author
of
errors
or
simply
create
templates
that
enforce
that
structure.
1.4.2
Testing
Practices
and
Tools
The
accessibility
of
interactive
content
cannot
be
confirmed
by
static
checks
alone.
Developers
of
interactive
content
should
test
for
device-independent
access
to
widgets
and
applications,
and
should
verify
accessibility
API
access
to
all
content
and
changes
during
user
interaction.
1.5
Assistive
Technologies
Programmatic
access
to
accessibility
semantics
is
essential
for
assistive
technologies.
For
more
information,
refer
to
the
Assistive
Technologies
section
in
[
WAI-ARIA
].
2.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MAY
,
MUST
,
MUST
NOT
,
and
SHOULD
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
Normative
sections
provide
requirements
that
authors,
user
agents
and
assistive
technologies
MUST
follow
for
an
implementation
to
conform
to
this
specification.
Non-normative
sections
provide
information
useful
to
understanding
the
specification.
Such
sections
may
contain
examples
of
recommended
practice,
but
it
is
not
required
to
follow
such
recommendations
in
order
to
conform
to
this
specification.
3.
Important
Terms
This
section
is
non-normative.
While
some
terms
are
defined
in
place,
the
following
definitions
are
used
throughout
this
document.
relies
on
services
provided
by
a
user
agent
to
retrieve
and
render
Web
content
works
with
a
user
agent
or
web
content
itself
through
the
use
of
APIs,
and
provides
services
beyond
those
offered
by
the
user
agent
to
facilitate
user
interaction
with
web
content
by
people
with
disabilities
This
definition
may
differ
from
that
used
in
other
documents.
Examples
of
assistive
technologies
that
are
important
in
the
context
of
this
document
include
the
following:
screen
magnifiers,
which
are
used
to
enlarge
and
improve
the
visual
readability
of
rendered
text
and
images;
screen
readers,
which
are
most-often
used
to
convey
information
through
synthesized
speech
or
a
refreshable
Braille
display;
text-to-speech
software,
which
is
used
to
convert
text
into
synthetic
speech;
speech
recognition
software,
which
is
used
to
allow
spoken
control
and
dictation;
alternate
input
technologies
(including
head
pointers,
on-screen
keyboards,
single
switches,
and
sip/puff
devices),
which
are
used
to
simulate
the
keyboard;
alternate
pointing
devices,
which
are
used
to
simulate
mouse
pointing
and
clicking.
Attribute
In
this
specification,
attribute
is
used
as
it
is
in
markup
languages.
Attributes
are
structural
features
added
to
elements
to
provide
information
about
the
states
and
properties
of
the
object
represented
by
the
element.
Class
A
set
of
instance
objects
that
share
similar
characteristics.
Element
In
this
specification,
element
is
used
as
it
is
in
markup
languages.
Elements
are
the
structural
elements
in
markup
language
that
contains
the
data
profile
for
objects
.
Event
A
programmatic
message
used
to
communicate
discrete
changes
in
the
state
of
an
object
to
other
objects
in
a
computational
system.
User
input
to
a
web
page
is
commonly
mediated
through
abstract
events
that
describe
the
interaction
and
can
provide
notice
of
changes
to
the
state
of
a
document
object.
In
some
programming
languages,
events
are
more
commonly
known
as
notifications.
Object
In
the
context
of
user
interfaces,
an
item
in
the
perceptual
user
experience,
represented
in
markup
languages
by
one
or
more
elements
,
and
rendered
by
user
agents
.
In
the
context
of
programming,
the
instantiation
of
one
or
more
classes
and
interfaces
which
define
the
general
characteristics
of
similar
objects.
An
object
in
an
accessibility
API
may
represent
one
or
more
DOM
objects.
Accessibility
APIs
have
defined
interfaces
that
are
distinct
from
DOM
interfaces.
Ontology
A
description
of
the
characteristics
of
classes
and
how
they
relate
to
each
other.
Main
indicator
of
type.
This
semantic
association
allows
tools
to
present
and
support
interaction
with
the
object
in
a
manner
that
is
consistent
with
user
expectations
about
other
objects
of
that
type.
Semantics
The
meaning
of
something
as
understood
by
a
human,
defined
in
a
way
that
computers
can
process
a
representation
of
an
object
,
such
as
elements
and
attributes
,
and
reliably
represent
the
object
in
a
way
that
various
humans
will
achieve
a
mutually
consistent
understanding
of
the
object.
State
A
state
is
a
dynamic
property
expressing
characteristics
of
an
object
that
may
change
in
response
to
user
action
or
automated
processes.
States
do
not
affect
the
essential
nature
of
the
object,
but
represent
data
associated
with
the
object
or
user
interaction
possibilities.
See
clarification
of
states
versus
properties
.
Taxonomy
A
hierarchical
definition
of
how
the
characteristics
of
various
classes
relate
to
each
other,
in
which
classes
inherit
the
properties
of
superclasses
in
the
hierarchy.
A
taxonomy
can
comprise
part
of
the
formal
definition
of
an
ontology
.
User
Agent
Any
software
that
retrieves,
renders
and
facilitates
end
user
interaction
with
Web
content.
This
definition
may
differ
from
that
used
in
other
documents.
Widget
Discrete
user
interface
object
with
which
the
user
can
interact.
Widgets
range
from
simple
objects
that
have
one
value
or
operation
(e.g.,
check
boxes
and
menu
items),
to
complex
objects
that
contain
many
managed
sub-objects
(e.g.,
trees
and
grids).
4.
Digital
Publishing
Roles
This
section
defines
additions
to
the
WAI-ARIA
role
taxonomy
and
describes
the
characteristics
and
properties
of
all
roles
.
See
ARIA
Roles
for
descriptions
of
the
fields
provided
by
this
module.
4.1
Definition
of
Roles
Below
is
an
alphabetical
list
of
WAI-ARIA
roles
to
be
used
by
rich
internet
application
authors.
A
section
or
statement
that
acknowledges
significant
contributions
by
persons,
organizations,
governments
and
other
entities
to
the
realization
of
the
work.
A
closing
statement
from
the
author
or
a
person
of
importance,
typically
providing
insight
into
how
the
content
came
to
be
written,
its
significance,
or
related
events
that
have
transpired
since
its
timeline.
A
link
that
allows
the
user
to
return
to
a
related
location
in
the
content
(e.g.,
from
a
footnote
to
its
reference
or
from
a
glossary
definition
to
where
a
term
is
used).
[Deprecated
in
DPUB-ARIA
1.1]
A
single
reference
to
an
external
source
in
a
bibliography.
A
biblioentry
typically
provides
more
detailed
information
than
its
reference(s)
in
the
content
(e.g.,
full
title,
author(s),
publisher,
publication
date,
etc.).
An
acknowledgment
of
the
source
of
integrated
content
from
third-party
sources,
such
as
photos.
Typically
identifies
the
creator,
copyright
and
any
restrictions
on
reuse.
[Deprecated
in
DPUB-ARIA
1.1]
One
of
a
collection
of
notes
that
occur
at
the
end
of
a
work,
or
a
section
within
it,
that
provides
additional
context
to
a
referenced
passage
of
text.
A
section
of
text
appearing
at
the
bottom
of
a
page
that
provides
context
about
the
current
work
and
location
within
it.
The
page
footer
is
distinct
from
the
body
text
and
normally
follows
a
repeating
template
that
contains
(possibly
truncated)
items
such
as
the
document
title,
current
section,
author
name(s),
and
page
number.
A
section
of
text
appearing
at
the
top
of
a
page
that
provides
context
about
the
current
work
and
location
within
it.
The
page
header
is
distinct
from
the
body
text
and
normally
follows
a
repeating
template
that
contains
(possibly
truncated)
items
such
as
the
document
title,
current
section,
author
name(s),
and
page
number.
A
major
structural
division
in
a
work
that
contains
a
set
of
related
sections
dealing
with
a
particular
subject,
narrative
arc
or
similar
encapsulated
theme.
A
navigational
aid
that
provides
an
ordered
list
of
links
to
the
major
sectional
headings
in
the
content.
A
table
of
contents
may
cover
an
entire
work,
or
only
a
smaller
section
of
it.
doc-abstract
(role)
A
short
summary
of
the
principal
ideas,
concepts
and
conclusions
of
the
work,
or
of
a
section
or
excerpt
within
it.
<sectionrole="doc-abstract"aria-label="Abstract"><p>Accessibility of web content requires semantic information about widgets, structures,
and behaviors …</p>
</
section
>
A
section
or
statement
that
acknowledges
significant
contributions
by
persons,
organizations,
governments
and
other
entities
to
the
realization
of
the
work.
A
closing
statement
from
the
author
or
a
person
of
importance,
typically
providing
insight
into
how
the
content
came
to
be
written,
its
significance,
or
related
events
that
have
transpired
since
its
timeline.
A
link
that
allows
the
user
to
return
to
a
related
location
in
the
content
(e.g.,
from
a
footnote
to
its
reference
or
from
a
glossary
definition
to
where
a
term
is
used).
<asideid="fn01"role="doc-footnote"><arole="doc-backlink"href="#fnref01">1.</a>
Additional results of this study and
similar studies can be found at …
</
aside
>
[Deprecated
in
DPUB-ARIA
1.1]
A
single
reference
to
an
external
source
in
a
bibliography.
A
biblioentry
typically
provides
more
detailed
information
than
its
reference(s)
in
the
content
(e.g.,
full
title,
author(s),
publisher,
publication
date,
etc.).
Note
The
doc-biblioentry
role
was
designed
for
use
as
a
list
item,
but
due
to
clarifications
in
the
WAI-ARIA
specification,
it
is
not
valid
as
a
child
of
the
list
role.
As
the
doc-bibliography
role
already
identifies
a
section
of
bibliography
entries,
authors
are
instead
advised
to
use
the
list
and
listitem
roles
when
native
HTML
elements
cannot
be
used
to
structure
the
entries.
An
acknowledgment
of
the
source
of
integrated
content
from
third-party
sources,
such
as
photos.
Typically
identifies
the
creator,
copyright
and
any
restrictions
on
reuse.
<prole="doc-credit">
Page 62, Table 3.1 from <cite>“Economic Foundations of Cost-Effectiveness Analysis”</cite>
by A. M. Garber and C. E. Phelps …
</
p
>
[Deprecated
in
DPUB-ARIA
1.1]
One
of
a
collection
of
notes
that
occur
at
the
end
of
a
work,
or
a
section
within
it,
that
provides
additional
context
to
a
referenced
passage
of
text.
Note
The
doc-endnote
role
was
designed
for
use
as
a
list
item,
but
due
to
clarifications
in
the
WAI-ARIA
specification,
it
is
not
valid
as
a
child
of
the
list
role.
As
the
doc-endnotes
role
already
identifies
a
section
of
endnotes,
authors
are
instead
advised
to
use
the
list
and
listitem
roles
when
native
HTML
elements
cannot
be
used
to
structure
the
entries.
The
doc-footnote
role
can
be
used
within
each
list
item
to
identify
individual
notes
when
necessary.
<sectionrole="doc-endnotes"><h2>Notes</h2><ol><liid="6baa07af"><prole="doc-footnote">Additional results of this study can be found at … </p></li><liid="7b2c0555"><prole="doc-footnote">…</p></li>
…
</ol>
</
section
>
<blockquoterole="doc-epigraph"><p>“Would you tell me please, which way I ought to go from here?”</p><p>“That depends a good deal on where you want to get to,” said the cat.</p>
</
blockquote
>
Ancillary
information,
such
as
a
citation
or
commentary,
that
provides
additional
context
to
a
referenced
passage
of
text.
The
doc-footnote
role
is
only
for
representing
individual
notes
that
occur
within
the
body
of
a
work.
For
collections
of
notes
that
occur
at
the
end
of
a
section,
see
doc-endnotes
.
A
brief
dictionary
of
new,
uncommon
or
specialized
terms
used
in
the
content.
The
structure
of
a
glossary
SHOULD
make
it
possible
for
end
users
to
identify
each
term
and
associated
definition
(e.g.,
using
the
[
HTML
]
dl
or
dfn
elements).
<sectionrole="doc-glossary"aria-labelledby="glosshd"><h2id="glosshd">Glossay of Technical Terms</h2><ul><liid="gtt00110001"><dfn>algorithm</dfn> A set of rules …</li>
…
</ul>
</
section
>
<sectionrole="doc-notice"><imgsrc="warning.png"alt="warning icon"/><p>Just because you can include a font doesn’t mean you should.
Think carefully about readability. Also, be respectful of intellectual property.
There are many excellent free open source fonts available.</p>
</
section
>
Authors
SHOULD
include
a
label
when
the
notice
needs
to
be
navigable
to.
A
separator
denoting
the
position
before
which
a
break
occurs
between
two
contiguous
pages
in
a
statically
paginated
version
of
the
content.
Page
break
locators
are
also
commonly
used
to
provide
static
markers
in
purely
digital
publications
(i.e.,
where
no
statically
paginated
equivalent
exists).
These
markers
provide
consistent
navigation
regardless
of
differences
in
font
and
screen
size
that
can
otherwise
affect
the
dynamic
pagination
of
the
content.
Authors
MUST
ensure
the
name
of
the
page
break
is
an
end
user-consumable
page
number
that
identifies
the
page
that
is
beginning
so
that
assistive
technologies
can
announce
the
page
as
needed
(e.g.,
in
a
command
to
indentify
the
current
page).
A
section
of
text
appearing
at
the
bottom
of
a
page
that
provides
context
about
the
current
work
and
location
within
it.
The
page
footer
is
distinct
from
the
body
text
and
normally
follows
a
repeating
template
that
contains
(possibly
truncated)
items
such
as
the
document
title,
current
section,
author
name(s),
and
page
number.
The
doc-pagefooter
role
MUST
be
used
on
every
instance
of
the
page
footer.
A
section
of
text
appearing
at
the
top
of
a
page
that
provides
context
about
the
current
work
and
location
within
it.
The
page
header
is
distinct
from
the
body
text
and
normally
follows
a
repeating
template
that
contains
(possibly
truncated)
items
such
as
the
document
title,
current
section,
author
name(s),
and
page
number.
The
doc-pageheader
role
MUST
be
used
on
every
instance
of
the
page
header.
A
major
structural
division
in
a
work
that
contains
a
set
of
related
sections
dealing
with
a
particular
subject,
narrative
arc
or
similar
encapsulated
theme.
A
distinctively
placed
or
highlighted
quotation
from
the
current
content
designed
to
draw
attention
to
a
topic
or
highlight
a
key
point.
Unlike
a
passage
quoted
from
another
source,
a
pullquote
is
a
direct
repetition
of
text
in
the
current
document.
As
a
result,
authors
must
ensure
that
the
presentational
occurrence
is
hidden
from
users
of
assistive
technologies
(e.g.,
using
the
aria-hidden
attribute).
The
following
example
shows
the
identification
of
a
pullquote
that
will
be
presented
elsewhere
(e.g.,
via
a
script).
In
this
case,
the
pullquote
is
not
hidden
as
the
marked
text
is
not
presentational.
<p>… I may die, but first you, my tyrant and tormentor, shall curse the sun that gazes on your misery.
<spanid="pq01"role="doc-pullquote">Beware, for I am fearless and therefore powerful.</span>
I
will
watch
with
the
wiliness
of
a
snake,
that
I
may
sting
with
its
venom.
…
</
p
>
The
next
example
shows
a
pullquote
that
duplicates
the
text.
This
quote
is
hidden
because
it
is
for
presentational
purposes
only.
<p>… Better habits pave the way to growth, and growth leads to greater happiness.</p><asiderole="doc-pullquote"aria-hidden="true">
Better habits pave the way to growth, and growth leads to greater happiness.
</
aside
>
<sectionrole="doc-qna"><h2>Interview with the Author</h2><dl><dt>Q: When did you begin writing this book?</dt><dd>A: I first got the idea …</dd>
…
</dl>
</
section
>
<asiderole="doc-tip"><h3>Tip</h3><p>You can assign a variable a new value that is the result
of an expression involving its previous value.</p>
</
aside
>
A
navigational
aid
that
provides
an
ordered
list
of
links
to
the
major
sectional
headings
in
the
content.
A
table
of
contents
may
cover
an
entire
work,
or
only
a
smaller
section
of
it.
<navrole="doc-toc"><h2>Contents</h2><olrole="directory"><li><ahref="preface_001.xhtml">Original Transcriber’s Notes:</a></li><li><ahref="introduction_001.xhtml">ETYMOLOGY.</a></li><li><ahref="epigraph_001.xhtml">EXTRACTS (Supplied by a Sub-Sub-Librarian).</a></li><li><ahref="chapter_001.xhtml">Chapter 1. Loomings.</a></li>
…
</ol>
</
nav
>
The
following
people
contributed
to
the
development
of
this
document.
C.1
Participants
active
in
the
DPUB-ARIA
task
force
at
the
time
of
publication
Michael
Cooper
(
W3C
Staff)
Joanmarie
Diggs
(Igalia,
S.L.)
Matt
Garrish
(DAISY
Consortium)
James
Nurthen
(Adobe)
Tzviya
Siegman
(Wiley)
C.2
Enabling
funders
This
publication
has
been
funded
in
part
with
U.S.
Federal
funds
from
the
Department
of
Education,
National
Institute
on
Disability,
Independent
Living,
and
Rehabilitation
Research
(NIDILRR),
initially
under
contract
number
ED-OSE-10-C-0067
and
currently
under
contract
number
HHSP23301500054C.
The
content
of
this
publication
does
not
necessarily
reflect
the
views
or
policies
of
the
U.S.
Department
of
Education,
nor
does
mention
of
trade
names,
commercial
products,
or
organizations
imply
endorsement
by
the
U.S.
Government.