W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2010

HTML5 bugs & UAAG

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 9 Sep 2010 12:01:33 -0500
Message-ID: <AANLkTi=3AFTvnO4bS-MGMvYHFuYA9bmEv4OSP9UyZV-0@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
Bug 8647 - Define tab order for IFrame
Problem:
When iframes are processed in keyboard navigation order, the tab order
should tab in document order from outside the iframe, into the first
focusable item in the iframe, then when it reaches the last focusable
item in the iframe, the next tab should exit the iframe and move to
the next item in tab order in the parent document. This is because a
lot of uses of iframe are to support security in the web page.

Response:
Status: Rejected
Change Description: no spec change
Rationale: I agree in principle with what is described, but I don't
understand why HTML should define this. This seems like a platform
convention-- if a platform has a different behaviour, it should be
conforming for a user agent to do it. It would be stupid, but there's
no interoperability reason to disallow it. It would be like the UA
insisting on having the window to all Web pages be 100 pixels square.
It would be stupid, accessibility would suffer, but there may be times
where it's the right thing, and more importantly it's not an interop
problem, so it should be allowed.
UAAG
I agree with the first part- follow the platform convention. If there
is no convention- then tab into iframe and trough content, then out of
iframe back to main content. I also believe this is covered under
compound documents (need spec reference).  This should be a UA issue.
For AT or the UA user should be able to quickly jump out of the iframe
back to the parent browsing context. JAWS – uses a frame list to allow
users to quickly navigate between and among frames (iframe too – I
think…need to verify). In IE F6 moves between frames (IFrame?? Verify)

HTML5 Reference 4.8.2 The iframe element
http://dev.w3.org/html5/spec/Overview.html#the-iframe-element

Bug 8648 - Title attribute on the IFrame element
Problem:
Suggest including advice related to iframe about the use of the title
element to identify frames from a navigation perspective. (ex. In
speech media, the title attribute provides a label for an iframe,
allowing users to more easily navigate to and explore individual
sections.)
Response:
Status: Did Not Understand Request
Change Description: no spec change
Rationale: How is this different than with any other element? It's not
entirely clear to me why <iframe> is special here. Wouldn't you want
title="" to be used to aid navigation in general?

UAWG -
HTML 4.01 & 5 has a @name attribute on the ‘frame’ element. HTML5 has
@name on the ‘iframe’ element. In none if the specs is @name required.
If it were, it would benefit accessibility. @Title could also be used
as it is available to all elements.

HTML5 Reference 4.8.2 The iframe element
http://dev.w3.org/html5/spec/Overview.html#the-iframe-element
http://dev.w3.org/html5/spec/Overview.html#frames-and-framesets
http://dev.w3.org/html5/spec/Overview.html#frameset
http://dev.w3.org/html5/spec/Overview.html#frame
http://dev.w3.org/html5/spec/Overview.html#attr-iframe-name


============================================

Bug 8666 - Keyboard accessible date pickers

Problem:
Date pickers should be both keyboard accessible and able to be  magnified in
the browser. This is probably beyond the scope of HTML5  itself and
covered in UAAG but mention it just to clarify.

Response:
Status: Did Not Understand Request
Change Description: no spec change
Rationale: _Everything_ should be both keyboard accessible and able to be
magnified, just like everything should be selectable, or searchable, or
anything else. Why would we call this out specifically for the type=date
control?

UAAG:
Agree with editor – non-issue

HTML5 Reference 4.10.7.1.7 Date and Time state
http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-and-time-state

=====================================

Bug 8682 - Tab and reading order for context menus

Problem:
The tab order and reading order of context menus should be defined in
the spec to clarify usage.

Response:
Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Wouldn't this be a platform-specific
issue? What is the interoperability concern with the tab order of
context menus? Indeed, do menus support tabbing at all on any
platform?

UAAG:
There is no tab order in context menus, only arrows (at least in
windows). Open context menu, start at top and arrow down. We do need
some indicator for when an author context menu is available.
HTML5 Reference  4.11.4 The menu element and 4.11.4.3 Context menus
http://dev.w3.org/html5/spec/Overview.html#context-menus

The contextmenu attribute gives the element's context menu. The value
must be the ID of a menu element in the DOM. If the node that would be
obtained by the invoking the getElementById() method using the
attribute's value as the only argument is null or not a menu element,
then the element has no assigned context menu. Otherwise, the
element's assigned context menu is the element so identified.
When an element's context menu is requested (e.g. by the user
right-clicking the element, or pressing a context menu key), the UA
must fire a simple event named contextmenu that bubbles and is
cancelable at the element for which the menu was requested.
=======================================

Bug 8743 - Auditory icons clashing with AT

Problem:
The specification states: "Icons could be auditory icons, visual
icons, or other kinds of icons."

Are 'auditory icons' meant to be played by the user agent as soon as a page
loads? This may clash with AT such as screen readers especially if the audio
sample is long. Is there a way to manage this?

Response:
Status: Rejected
Change Description: no spec change
Rationale: How icons are used is entirely up to the UA.

UAAG: agree with editor. Handling of auditory icons is a UA issue. We
need to address it.
HTML 5 reference 4.12.4.7 Link type "icon"
http://dev.w3.org/html5/spec/Overview.html#rel-icon

The icon keyword may be used with link elements. This keyword creates
an external resource link.
The specified resource is an icon representing the page or site, and
should be used by the user agent when representing the page in the
user interface.
Icons could be auditory icons, visual icons, or other kinds of icons.
If multiple icons are provided, the user agent must select the most
appropriate icon according to the type, media, and sizes attributes.
If there are multiple equally appropriate icons, user agents must use
the last one declared in tree order. If the user agent tries to use an
icon but that icon is determined, upon closer examination, to in fact
be inappropriate (e.g. because it uses an unsupported format), then
the user agent must try the next-most-appropriate icon as determined
by the attributes.
There is no default type for resources given by the icon keyword.
However, for the purposes of determining the type of the resource,
user agents must expect the resource to be an image.
==========================

Bug 8751 - User should have ability to override automatic scrolling

Problem:
There should be a way for the user to override automatic scrolling. Automatic
scrolling can make the cursor jump in ways that causes the user to go through
extra steps to get back to what he was doing. This is a special hardship for
some users. This is another example of allowing for full accessibility by
giving the user a way to override inappropriate design.

Response:
Status: Accepted
Change Description: no spec change
Rationale: The spec already allows for this — that's why the scrolling
requirement is a "should" and not a "must" (only bringing the user's
attention to the given element is a "must", and the spec doesn't say
how the UA is to do that).

UAAG – Scripting problem! Perhaps use aria politeness levels for
scrolling? That must be an author call
HTML5 reference 7.3 Scrolling elements into view
http://www.w3.org/TR/html5/editing.html#scrolling-elements-into-view
element . scrollIntoView( [ top ] )
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.
The scrollIntoView([top]) method, when called, must cause the element
on which the method was called to have the attention of the user
called to it.
In a speech browser, this could happen by having the current playback
position move to the start of the given element.
If the element in question cannot be brought to the user's attention,
e.g. because it is hidden, or is not being rendered, then the user
agent must do nothing instead.
In visual user agents, if the argument is present and has the value
false, the user agent should scroll the element into view such that
both the bottom and the top of the element are in the viewport, with
the bottom of the element aligned with the bottom of the viewport. If
it isn't possible to show the entire element in that way, or if the
argument is omitted or is true, then the user agent should instead
align the top of the element with the top of the viewport. If the
entire scrollable part of the content is visible all at once (e.g. if
a page is shorter than the viewport), then the user agent should not
scroll anything. Visual user agents should further scroll horizontally
as necessary to bring the element to the attention of the user.
Non-visual user agents may ignore the argument, or may treat it in
some media-specific manner most useful to the user.




-- 
Jim Allan, Accessibility Coordinator & Webmaster

Texas School for the Blind and Visually Impaired

1100 W. 45th St., Austin, Texas 78756

voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/

"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 9 September 2010 17:02:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:39 UTC