-
This
version:
-
http://www.w3.org/MarkUp/2008/ED-xhtml-access-20081018
-
Latest
version:
-
http://www.w3.org/TR/xhtml-access
-
Previous
version:
-
http://www.w3.org/TR/2008/WD-xhtml-access-20080526
-
Diff
from
previous
version:
-
xhtml-access-diff.html
-
Editors:
-
Mark
Birbeck,
webBackplane
mark.birbeck@webBackplane.com
-
Shane
McCarron
,
Applied
Testing
and
Technology,
Inc.
-
Steven
Pemberton
,
CWI
/
W3C
®
-
T.
V.
Raman
,
Google,
Inc.
-
Richard
Schwerdtfeger
,
IBM
Corporation
This
document
is
also
available
in
these
non-normative
formats:
PostScript
version
,
PDF
version
,
ZIP
archive
,
and
Gzip'd
TAR
archive
.
The
English
version
of
this
specification
is
the
only
normative
version.
Non-normative
translations
may
also
be
available.
Copyright
©
2007-2008
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
The
XHTML
Access
module
defines
an
element
that,
when
used
in
conjunction
with
other
XHTML
modules
in
XHTML
Family
Markup
Languages,
enables
a
more
robust
accessibility
model
than
is
presently
possible.
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
http://www.w3.org/TR/.
This
is
a
Candidate
Recommendation
produced
by
the
XHTML
2
Working
Group
.
It
reflects
a
consensus
among
the
Working
Group
members,
in
conjunction
with
input
from
the
User
Agent
Accessibility
Guidelines
Working
Group
and
others
in
the
community.
If
reflects
changes
arising
from
comments
during
the
Last
Call
period.
A
"Disposition
of
Comments"
report
about
that
last
call
is
available
at
http://www.w3.org/MarkUp/2008/xhtml-access-lc-doc-20081018.html
.
This
specification
is
considered
stable
by
the
XHTML
2
Working
Group,
and
is
available
for
public
review
during
the
Candidate
Recommendation
review
period.
The
exit
criteria
for
this
period
is
@@@TBD@@@
that
there
be
at
least
two
implementations
that
incorporate
the
access
element
into
a
markup
language
and
support
all
the
features
required
by
this
specification.
The
review
period
will
end
@@@TBD@@@
at
the
earliest.
An
implementation
report
will
be
made
available
at
http://www.w3.org/MarkUp/2008/xhtml-access-10-implementation.html
.
The
goals
of
the
XHTML
2
Working
Group
are
discussed
in
the
XHTML
2
Working
Group
charter
.
This
document
was
produced
by
a
group
operating
under
the
5
February
2004
W3C
Patent
Policy
.
W3C
maintains
a
public
list
of
any
patent
disclosures
made
in
connection
with
the
deliverables
of
the
group;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
Essential
Claim(s)
must
disclose
the
information
in
accordance
with
section
6
of
the
W3C
Patent
Policy
.
Publication
as
a
Candidate
Recommendation
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.
Please
report
errors
in
this
specification
to
www-html-editor@w3.org
(
archive
).
It
is
inappropriate
to
send
discussion
email
to
this
address.
Public
discussion
may
take
place
on
www-html@w3.org
(
archive
).
This
section
is
informative.
Most
desktop
applications
provide
a
way
for
the
user
to
navigate
or
activate
specific
functionality
through
the
use
of
the
keyboard
alone,
particularly
by
using
keyboard
shortcuts,
which
are
a
single
key
or
combination
of
keys.
Web
pages
and
Web
Applications
have
traditionally
been
less
able
to
do
so
due
to
conflicting
shortcuts
within
the
operating
system
or
browser
itself,
and
due
also
to
a
lack
of
a
coherent
robust
mechanism.
Thus,
Web
resources
have
relied
primarily
on
interaction
via
pointing
devices,
such
as
a
mouse.
This
specification
defines
a
way
to
assign
character
mappings
(e.g.
keyboard
shortcuts,
or
keys
combinations)
to
navigate
to
specific
elements
or
sequential
sets
of
elements,
which
may
be
activated
by
the
user,
or
which
may
be
activated
immediately,
based
on
the
author's
intent.
It
also
addresses
the
need
for
end
users
to
be
able
to
remap
these
keys
for
personalizing
the
interaction,
and
describes
how
a
browser
might
expose
these
character
mappings
to
the
user.
This
document
contains
a
single
module
designed
to
be
used
to
help
make
XHTML-family
markup
languages
more
effective
at
supporting
the
needs
of
the
Accessibility
Community.
It
has
been
developed
in
conjunction
with
the
W3C's
Web
Accessibility
Initiative
and
other
interested
parties.
The
module
herein
contains
functionality
that
is
the
logical
successor
to
the
accesskey
attribute
that
is
used
in
the
XHTML
Forms
and
Basic
Forms
modules.
This
section
is
normative
.
The
keywords
"MUST",
"MUST
NOT",
"REQUIRED",
"SHALL",
"SHALL
NOT",
"SHOULD",
"RECOMMENDED",
"MAY",
and
"OPTIONAL"
in
this
document
are
to
be
interpreted
as
described
in
[
RFC2119
].
Note
that
all
examples
in
this
document
are
informative,
and
are
not
meant
to
be
interpreted
as
normative
requirements.
XHTML
Access
is
not
a
stand-alone
document
type.
It
is
intended
to
be
integrated
into
other
XHTML
Family
Markup
Languages.
A
conforming
XHTML
Access
document
is
a
document
that
requires
only
the
facilities
described
as
mandatory
in
this
specification
and
the
facilities
described
as
mandatory
in
its
host
language.
Such
a
document
must
meet
all
the
following
criteria:
-
The
document
MUST
conform
to
the
constraints
expressed
in
its
host
language
implementation.
-
If
the
host
language
is
not
in
the
XHTML
namespace,
and
the
host
language
does
not
incorporate
this
module
into
its
own
namespace,
then
the
document
MUST
contain
an
xmlns:
declaration
for
the
XHTML
Access
namespace
[
XMLNAMES
]
.
The
namespace
for
XHTML
Access
Module
is
defined
to
be
http://www.w3.org/1999/xhtml
.
An
example
start
tag
of
a
root
element
might
look
like:
Example
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
When
XHTML
Access
is
included
in
a
host
language,
all
of
the
facilities
required
in
this
specification
MUST
be
included
in
the
host
language.
In
addition,
the
element
defined
in
this
specification
MUST
be
included
in
the
content
model
of
the
host
language.
The
element
defined
in
this
specification
MAY
be
incorporated
into
the
namespace
of
the
host
language,
or
it
MAY
remain
in
the
XHTML
namespace.
Finally,
XHTML
Access
requires
the
availability
of
the
XHTML
Role
Attribute
Module
[
XHTMLROLE
].
A
conforming
user
agent
MUST
support
all
of
the
features
required
in
this
specification.
This
section
is
normative
.
This
module
defines
the
access
element.
|
Element
|
Attributes
|
Minimal
Content
Model
|
|
access
|
activate
,
key
,
media
,
order
,
targetid
,
targetrole
|
EMPTY
|
When
this
module
is
used,
it
adds
the
access
element
to
the
content
model
of
the
head
element
as
defined
in
the
XHTML
Structure
Module.
Implementations:
XML
Schema
,
XML
DTD
The
access
element
assigns
a
mapping
between
"keys"
or
other
events
to
elements
within
a
document.
Actuating
the
mapping
results
in
the
element
gaining
focus
and
potentially
in
additional
events
being
activated.
An
access
element
must
have
either
a
targetrole
or
a
targetid
attribute
specified.
If
neither
a
targetrole
nor
a
targetid
attribute
are
specified,
the
user
agent
MUST
NOT
define
a
mapping
nor
dispatch
any
events.
The
access
element
allows
an
author
to
specify
a
relationship
between
"key(s)"
or
other
events
and
one
or
more
elements
within
a
document.
When
a
mapped
event
is
triggered,
one
of
the
specified
target
elements
gains
focus,
and
one
or
more
other
events
(such
as
an
'activate'
event)
may
also
be
dispatched
to
that
element.
The
target
elements
are
specified
by
means
of
the
targetid
or
targetrole
attributes,
and
these
elements
may
each
contain
multiple
targets,
to
allow
sequential
focus
by
successively
triggering
the
associated
key(s)
or
event(s).
If
the
access
element's
activate
attribute
has
the
value
'true',
then
in
addition
to
receiving
focus,
the
target
element
will
be
activated,
if
permitted
by
the
user's
settings.
Additionally,
using
XML
Events
[
XMLEVENTS
],
one
or
more
other
events
may
also
be
dispatched
to
the
element.
An
access
element
must
have
either
a
targetrole
or
a
targetid
attribute
specified.
If
neither
a
targetrole
nor
a
targetid
attribute
are
specified,
or
if
there
are
no
matching
elements
in
the
document,
the
user
agent
MUST
NOT
define
a
mapping
for
this
element,
nor
change
focus
nor
dispatch
any
events
based
on
this
element.
Attributes
The
activate
attribute
indicates
whether
a
target
element
should
be
activated
or
not
once
it
obtains
focus.
The
default
value
for
this
attribute
is
"false",
indicating
that
the
element
will
not
be
"activated".
User
agents
MUST
provide
mechanisms
for
overriding
the
author
setting
with
user-specified
settings
in
order
to
ensure
that
the
act
of
moving
content
focus
does
not
cause
the
user
agent
to
take
any
further
action
(as
per
Checkpoint
9.5
of
UAAG
1.0
[
UAAG1
]).
User
agents
MUST
provide
keyboard
mechanisms
for
"activating"
any
event
associated
with
the
focused
element
(as
per
Checkpoint
1.2
of
UAAG
1.0).
User
agents
SHOULD
make
available
the
list
of
events
associated
with
the
focused
element
(as
per
Checkpoint
9.6
of
UAAG
1.0).
This
attribute
assigns
one
or
more
key
mappings
to
an
access
shortcut.
The
value
of
is
attribute
is
one
or
more
single
characters
from
the
document
character
set.
The
key
attribute
represents
an
abstraction.
The
use
of
the
name
"key"
for
this
attribute
is
historical
and
does
not
mean
that
there
is
any
association
with
a
specific
"key"
on
a
keyboard,
per
se
.
It
is
up
to
the
user
agent
to
provide
a
mechanism
for
mapping
the
document
character
set
value(s)
of
the
attribute
to
the
input
methods
available
to
the
user
agent.
For
instance,
on
some
systems
a
user
may
have
to
press
an
"alt"
or
"cmd"
key
in
addition
to
the
access
key.
On
other
systems
there
may
be
voice
commands,
or
gestures
with
a
mouse,
an
eye
tracking
input
device,
etc.
Regardless
of
the
mechanism,
the
result
is
that
it
appears
to
the
access
element
processor
as
if
the
defined
key
was
entered.
A
user
entering
any
of
the
keys
defined
in
an
access
element
moves
focus
from
its
current
position
to
the
next
element
in
navigation
order
that
has
one
of
the
referenced
role
or
id
values
(see
activate
for
information
on
how
the
element
may
be
activated).
Note
that
it
is
possible
to
deliver
alternate
events
via
[
XMLEVENTS
].
Note
also
that
the
concept
of
navigation
order
is
a
property
of
the
Host
Language,
and
is
not
defined
in
this
specification.
User
agents
MUST
provide
mechanisms
for
overriding
the
author
setting
with
user-specified
settings
in
order
to
ensure
that
the
act
of
moving
content
focus
does
not
cause
the
user
agent
to
take
any
further
action,
as
required
by
UAAG
1.0,
Checkpoint
9.5.
[
UAAG1
]
The
character
assigned
to
a
key,
and
its
relationship
to
a
role
or
id
attribute
SHOULD
be
treated
as
an
author
suggestion.
User
agents
MAY
override
any
key
assignment
(e.g.,
if
an
assignment
interferes
with
the
operation
of
the
user
interface
of
the
user
agent,
if
the
key
is
not
available
on
a
device,
if
a
key
is
used
by
the
operating
environment).
User
agents
MUST
also
allow
users
to
override
author
assigned
keys
with
their
own
key
assignments
(see
Checkpoint
11.3
of
UAAG
1.0).
If
a
user
chooses
to
change
the
key
binding,
the
resultant
user-defined
remapping
SHOULD
persist
across
sessions.
If
no
key
attribute
is
specified,
the
user
agent
SHOULD
assign
a
key
and
alert
the
user
to
the
key
mapping.
The
resultant
user
agent
assigned
key
mapping
SHOULD
persist
across
sessions.
It
is
common
for
user
agents
to
provide
a
visual
hint
for
accessing
features
via
keyboard
shortcuts,
such
as
showing
the
shortcut
next
to
a
menu
item,
or
underlining
the
shortcut
character
letter
in
a
label.
The
rendering
of
such
visual
hints
about
access
keys
depends
on
the
user
agent.
We
recommend
that
authors
include
the
access
key
character
in
label
text
or
wherever
the
access
key
is
to
apply.
If
the
user
agent
can
recognize
that
the
currently
mapped
access
key
character
appears
in
the
label
text
of
the
element
to
which
it
is
mapped,
then
the
user
agent
may
render
the
character
in
such
a
way
as
to
emphasize
its
role
as
the
access
key
and
distinguish
it
from
other
characters
(e.g.,
by
underlining
it).
A
conforming
user
agent
SHOULD
also
provide
a
centralized
view
of
the
current
access
key
assignments
(see
Checkpoint
11.1
and
Checkpoint
11.2
of
UAAG
1.0).
Authors
MUST
NOT
assign
the
same
key
value
to
more
than
one
active
access
element.
Note
that
it
is
possible
to
have
an
access
element
be
inactive
through
the
use
of
the
media
attribute.
The
value
of
this
attribute
is
a
comma-separated
list
of
media
descriptors
for
which
this
access
element
is
intended.
When
the
value
of
this
attribute
matches
the
current
processing
media,
the
associated
access
element
is
considered
active
and
processed
normally;
otherwise
it
is
inactive
and
ignored.
The
default
value
for
this
attribute
is
all
.
The
order
attribute
indicates
how
this
access
element
should
determine
the
navigation
order
for
its
matching
elements
.
The
default
value,
document
,
indicates
that
the
items
MUST
be
traversed
in
document
order.
The
alternate
value,
list
,
indicates
that
the
navigation
order
of
matching
elements
is
determined
by
the
author-defined
order
of
items
in
the
list
of
targetid
or
targetrole
attribute
values.
For
the
sake
of
determining
navigation
order
,
elements
in
the
document
that
match
the
values
in
the
targetid
or
targetrole
attributes
are
called
matching
elements
,
and
all
elements
that
match
the
same
value
are
members
of
an
element
group
.
Note:
since
the
id
of
an
element
must
be
unique
within
a
valid
XML
document,
in
such
documents,
each
element
group
based
on
targetid
values
consist
of
no
more
than
one
matching
element
.
For
each
navigation
operation,
the
navigation
order
for
both
document-order
and
list-order
is
sensitive
to
the
current
focus
element.
For
document-order,
if
no
element
currently
has
focus
,
the
first
matching
element
in
the
document
MUST
be
the
focus
target
;
if
an
element
does
have
focus
,
the
next
matching
element
in
the
document
MUST
be
the
focus
target
.
For
list-order,
the
focus
target
navigation
order
is
determined
as
follows:
-
If
no
matching
element
of
this
access
element
currently
has
focus
,
the
focus
target
MUST
be
the
first
element
in
document
order
that
matches
the
first
element
group
.
If
there
is
no
such
element,
then
the
focus
target
is
the
first
element
that
matches
the
second
element
group
,
and
so
on.
-
If
a
matching
element
of
this
access
element
already
has
focus
:
-
If
there
are
additional
matching
elements
of
the
same
element
group
in
document
order,
then
focus
MUST
be
sent
to
the
next
matching
element
of
the
same
element
group
.
-
Otherwise,
focus
MUST
go
to
the
first
matching
element
(in
document
order)
of
the
next
element
group
.
-
If
there
are
no
remaining
elements
groups,
then
the
search
MUST
resume
from
the
first
element
group
.
The
location
of
the
next
matching
element
MUST
be
determined
each
time
the
access
element
is
triggered,
since
it
is
possible
that
between
events
the
contents
of
the
document
will
have
changed.
A
host
language
MUST
define
any
circumstances
under
which
an
element
would
not
qualify
as
a
matching
element
(e.g.,
in
XHTML
1.1
if
a
Form
control
were
"disabled"
it
might
not
qualify.)
The
targetid
attribute
specifies
one
or
more
space
separated
IDREF
s
related
to
target
elements
for
the
associated
event
(i.e.,
the
node
to
which
the
event
should
be
delivered).
The
targetrole
attribute
specifies
a
space
separated
list
of
CURIE
s
[
CURIE
]
that
maps
to
an
element
with
a
role
attribute
with
the
same
value.
If
a
targetid
and
a
targetrole
are
both
specified
for
an
element,
a
user
agent
MUST
only
use
the
values
from
the
the
targetid
attribute.
If
the
prefix
is
omitted
from
a
CURIE,
the
default
value
of
http://www.w3.org/1999/xhtml/vocab#
MUST
be
used.
Many
common
accessibility
roles
are
defined
by
the
vocabulary
at
that
URI.
See
[
XHTMLVOCAB
]
for
more
information.
Access
element
that
focuses
into
a
field
<access key="s"
title="Social Security Number"
targetrole="ss:number" />
Accessing
a
table
of
contents
<access key="c"
title="Table of Contents"
targetrole="toc" />
Access
that
moves
to
the
main
content
<access key="m"
title="Main content"
targetrole="main" />
Access
that
moves
among
form
controls
<access key="i"
title="Form Controls"
order="document"
targetrole="button checkbox option radio textbox" />
Access
element
that
goes
to
a
specific
element
<access key="u"
title="Username"
targetid="username" />
Access
element
with
no
specific
key
mapping
<access title="Navigation bar"
targetrole="navigation" />
This
appendix
is
normative
.
The
schema
implementation
of
XHTML
Access
Module
conforms
to
the
requirements
defined
in
[
XHTMLMOD
].
It
is
included
here
as
an
example
implementation.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
xmlns:xh11d="http://www.w3.org/1999/xhtml/datatypes/"
>
<xs:import namespace="http://www.w3.org/1999/xhtml/datatypes/"
schemaLocation="xhtml-datatypes-1.xsd" />
<xs:annotation>
<xs:documentation>
This is the XML Schema module for XHTML Access
$Id: xhtml-access-diff.html,v 1.4 2008/10/18 20:58:15 smccarro Exp $
</xs:documentation>
<xs:documentation source="xhtml-copyright-1.xsd"/>
<xs:documentation source="http://www.w3.org/TR/xhtml-role#A_role"/>
</xs:annotation>
<xs:attributeGroup name="xhtml.access.attlist">
<xs:attributeGroup ref="xhtml.Common.attrib"/>
<xs:attribute name="activate" default="no">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="key" type="xh11d:Character"/>
<xs:attribute name="media" type="xh11d:MediaDesc"/>
<xs:attribute name="order" default="document">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="document"/>
<xs:enumeration value="list"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="targetid">
<xs:simpleType>
<xs:list itemType="xs:IDREF"/>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="targetrole" type="xh11d:CURIEs"/>
</xs:attributeGroup>
<xs:group name="xhtml.access.content">
<xs:sequence/>
</xs:group>
<xs:complexType name="xhtml.access.type">
<xs:group ref="xhtml.access.content"/>
<xs:attributeGroup ref="xhtml.access.attlist"/>
</xs:complexType>
</xs:schema>
This
appendix
is
normative
.
The
DTD
implementation
of
XHTML
Access
Module
conforms
to
the
requirements
defined
in
[
XHTMLMOD
].
Consequently,
it
provides
a
Qualified
Names
sub-module,
and
a
module
file
for
the
XHTML
Access
Module
defined
in
this
specification.
<!-- ....................................................................... -->
<!-- XHTML Access Qname Module ............................................ -->
<!-- file: xhtml-access-qname-1.mod
This is XHTML Access - the Access Attribute Module for XHTML.
Copyright 2007-2008 W3C (MIT, ERCIM, Keio), All Rights Reserved.
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ENTITIES XHTML Access Attribute Qnames 1.0//EN"
SYSTEM "http://www.w3.org/MarkUp/DTD/xhtml-access-qname-1.mod"
Revisions:
(none)
....................................................................... -->
<!-- XHTML Access Attribute Qname (Qualified Name) Module
This module is contained in two parts, labeled Section 'A' and 'B':
Section A declares parameter entities to support namespace-
qualified names, namespace declarations, and name prefixing
for XHTML Access and extensions.
Section B declares parameter entities used to provide
namespace-qualified names for the XHTML access element:
%XHTML.access.qname; the xmlns-qualified name for access
...
XHTML Access extensions would create a module similar to this one.
-->
<!-- Section A: XHTML Access Attribute XML Namespace Framework ::::::::::::::: -->
<!-- 1. Declare a %XHTML.prefixed; conditional section keyword, used
to activate namespace prefixing. The default value should
inherit '%NS.prefixed;' from the DTD driver, so that unless
overridden, the default behavior follows the overall DTD
prefixing scheme.
-->
<!ENTITY % NS.prefixed "IGNORE" >
<!ENTITY % XHTML.prefixed "%NS.prefixed;" >
<!-- 2. Declare a parameter entity (eg., %XHTML.xmlns;) containing
the URI reference used to identify the XHTML Access Attribute namespace
-->
<!ENTITY % XHTML.xmlns "http://www.w3.org/1999/xhtml" >
<!-- 3. Declare parameter entities (eg., %XML.prefix;) containing
the default namespace prefix string(s) to use when prefixing
is enabled. This may be overridden in the DTD driver or the
internal subset of an document instance. If no default prefix
is desired, this may be declared as an empty string.
NOTE: As specified in [XMLNAMES], the namespace prefix serves
as a proxy for the URI reference, and is not in itself significant.
-->
<!ENTITY % XHTML.prefix "" >
<!-- 4. Declare parameter entities (eg., %XHTML.pfx;) containing the
colonized prefix(es) (eg., '%XHTML.prefix;:') used when
prefixing is active, an empty string when it is not.
-->
<![%XHTML.prefixed;[
<!ENTITY % XHTML.pfx "%XHTML.prefix;:" >
]]>
<!ENTITY % XHTML.pfx "" >
<!-- declare qualified name extensions here ............ -->
<!ENTITY % xhtml-access-qname-extra.mod "" >
%xhtml-access-qname-extra.mod;
<!-- 5. The parameter entity %XHTML.xmlns.extra.attrib; may be
redeclared to contain any non-XHTML Access namespace
declaration attributes for namespaces embedded in XML. The default
is an empty string. XLink should be included here if used
in the DTD.
-->
<!ENTITY % XHTML.xmlns.extra.attrib "" >
<!-- Section B: XML Qualified Names ::::::::::::::::::::::::::::: -->
<!-- 6. This section declares parameter entities used to provide
namespace-qualified names for the XHTML Access element.
-->
<!ENTITY % XHTML.access.qname "%XHTML.pfx;access" >
<!-- end of xhtml-access-qname-1.mod -->
<!-- ...................................................................... -->
<!-- XHTML Access Module .................................................. -->
<!-- file: xhtml-access-1.mod
This is XHTML Access - the Access Module for XHTML.
Copyright 2007-2008 W3C (MIT, ERCIM, Keio), All Rights Reserved.
This DTD module is identified by the PUBLIC and SYSTEM identifiers:
PUBLIC "-//W3C//ELEMENTS XHTML Access Element 1.0//EN"
SYSTEM "http://www.w3.org/MarkUp/DTD/xhtml-access-1.mod"
Revisions:
(none)
....................................................................... -->
<!ENTITY % Character.datatype "CDATA" >
<!ENTITY % CURIEs.datatype "CDATA" >
<!ENTITY % IDREFs.datatype "CDATA" >
<!ENTITY % MediaDesc.datatype "CDATA" >
<!ENTITY % XHTML.access.element "INCLUDE" >
<![%XHTML.access.element;[
<!ENTITY % XHTML.access.content "EMPTY" >
<!ENTITY % XHTML.access.qname "access" >
<!ELEMENT %XHTML.access.qname; %XHTML.access.content; >
<!-- end of XHTML.access.element -->]]>
<!ENTITY % XHTML.access.attlist "INCLUDE" >
<![%XHTML.access.attlist;[
<!ATTLIST %XHTML.access.qname;
%Common.attrib;
activate ( yes | no ) #IMPLIED
order ( document | list ) #IMPLIED
key %Character.datatype; #IMPLIED
media %MediaDesc.datatype; #IMPLIED
targetid %IDREFs.datatype; #IMPLIED
targetrole %CURIEs.datatype; #IMPLIED
>
<!-- end of XHTML.access.attlist -->]]>
<!-- end of xhtml-access-1.mod -->
This
appendix
is
normative
.
-
[
CURIE
]
-
"
CURIE
Syntax
1.0
",
W3C
Working
Draft,
M.
Birbeck,
S.
McCarron,
ed.
,
2
April
2008.
Available
at:
http://www.w3.org/TR/2008/WD-curie-20080402/
The
latest
version
is
available
at:
http://www.w3.org/TR/curie
-
[
DOM2EVENTS
]
-
"
Document
Object
Model
(DOM)
Level
2
Events
Specification
",
W3C
Recommendation,
T.
Pixley,
ed.
,
13
November
2000.
Available
at:
http://www.w3.org/TR/DOM-Level-2-Events/
The
latest
version
is
available
at:
http://www.w3.org/TR/DOM-Level-2-Events
-
[
IRI
]
-
"
Internationalized
Resource
Identifiers
(IRI)
",
RFC
3987,
M.Duerst,
M.
Suignard
January
2005.
Available
at:
http://www.ietf.org/rfc/rfc3987.txt
-
[RFC2119]
-
"
Key
words
for
use
in
RFCs
to
indicate
requirement
levels
",
RFC
2119,
S.
Bradner,
March
1997.
Available
at:
http://www.rfc-editor.org/rfc/rfc2119.txt
-
[XHTMLMOD]
-
"
Modularization
of
XHTML™
1.1
",
W3C
Recommendation,
D.
Austin
et
al.
,
eds.
,
8
October
2008.
Available
at:
http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008
The
latest
version
is
available
at:
http://www.w3.org/TR/xhtml-modularization
-
[XMLNAMES]
-
"
Namespaces
in
XML
",
W3C
Recommendation,
T.
Bray
et
al.
,
eds.
,
14
January
1999.
Available
at:
http://www.w3.org/TR/1999/REC-xml-names-19990114
The
latest
version
is
available
at:
http://www.w3.org/TR/REC-xml-names
-
[XHTMLROLE]
-
"
XHTML
Role
Attribute
Module
",
W3C
Working
Draft,
M.
Birbeck
et
al.
,
eds.
,
7
April
2008.
Available
at:
http://www.w3.org/TR/2008/WD-xhtml-role-20080407/
The
latest
version
is
available
at:
http://www.w3.org/TR/xhtml-role
-
[UAAG1]
-
"
User
Agent
Accessibility
Guidelines
1.0
".
Ian
Jacobs
et
al.
,
17
December
2002.
Available
at:
http://www.w3.org/TR/2002/REC-UAAG10-20021217
The
latest
version
is
available
at:
http://www.w3.org/TR/UAAG10
-
[XHTML2]
-
"
XHTML™
2.0
".
J.
Axelsson
et
al.
,
26
July
2006.
Available
at:
http://www.w3.org/TR/2006/WD-xhtml2-20060726
The
latest
version
is
available
at:
http://www.w3.org/TR/xhtml2
-
[
XHTMLVOCAB
]
-
"
XHTML
Vocabulary
",
XHTML
2
Working
Group.
Available
at:
http://www.w3.org/1999/xhtml/vocab
-
[XMLEVENTS]
-
"
XML
Events
",
W3C
Recommendation,
S.
McCarron
et
al.
,
eds.
,
14
October
2003.
Available
at:
http://www.w3.org/TR/2003/REC-xml-events-20031014
This
section
is
informative.
At
the
time
of
publication,
the
participants
in
the
W3C
XHTML
2
Working
Group
were: