Review of HTML5

kelly's comments

Kelly: User agents will need to
ensure to reflect the state of this attribute in their
accessibility APIs. This may be stating the obvious but is
worth calling out since there are various situations today
where AT products do or do not show the same text that is
visually displayed and this is another potential variable to
keep in mind.

<AllanJ> JA: if HTML says
'hidden' and CSS says "visible" who wins?

JA: If there is another CSS or
some other setting to make it visible, which prevails

KP: There needs to be a robust
user mechanism to allow the user to decide what is visible

JA: if the script changes an
element from hidden to visible, does it fire an event to
refresh the page or notify the user?

DT: There are notifications that
can be sent on the Mac that are specific to elements set on the
DOM tree.

<mth> for those who hide form
labels off screen with css position... it would have been
interesting to consider ".hidden" as as less of a kludge. this
seems to really hide and removes it from view of both AT and
screen?

<AllanJ> JS: do we tell HTML
that notification of user must be included in their
document

DT: Does HTML5 go into that much
detail for the user agent developer.

JA: Some of the details of how
the user agent should respond or be rendered is included in
HTML5. But not necessarily this detail that the user needs to
be notified.
... Is there some ability in the Accessibility API for
mechanisms for notification of layout changes.

DT: the major ones all support
it. But major AT developers may have their own mechanisms for
getting content information

JA: Does it have a generic
watcher to watch for DOM changes and pass that information to
the notification mechanism?

DT: the user agent notifies the
Accessibility API that a change has happened, then the
Accessibility API passes that ifnormation to the AT.

SH: We talked about Mutation
Events last week where HTML5 only fires mutation events when
there are changes to the DOM, so AT that is listeninng for
mutation events will pick it up. JAAAWS v.10 picks it up.
... HTML5 only says fire mutation event when appropriate, so
that is a problem because it leaves it up to the user agent
developer to determine what/when it is appropriate.
... ARIA has rules for determining the importance of mutation
event notifications. But that is not included in HTML5 yet.

DT: ARIA has different ratings
for alerts, it should be the AT to convey that information to
the user.

JA: We need to make a comment to
HTML5 and we need to add it to the UAAG guidelines.
... Based on what Simon and David said, the user agent must
fire a mutation event and let the accessibility API decide.

HTML5 section 7.4

Scrolls the element into view. If the top
argument is true, then the element will be scrolled to the top
of the viewport, otherwise it'll be scrolled to the bottom. The
default is the top.

DT: should it change the focus,
and what element should the focus go to?

KP: This is a big issue for
speech input users, because the user can be issuing a command
and the focus will be in a different place than the user
expected.

JA: It can change the point of
regard, change the keyboard focus, move the caret in
caret-browsing and it can fire an event.

RESOLUTION: Comment
on HTML5 7.4 (Editor's Draft) for HTML5 to clarify on the
scrollingIntoView whether it changes the the point of regard,
change the keyboard focus, move the caret or fire an event.
Does it do some or all of these?