W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2003

27 Feb 2003 telecon minutes

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 27 Feb 2003 15:00:05 -0600
To: w3c-wai-ua@w3.org
Message-id: <HDEAKIPKOHBCMDILOOPNAEMHFNAA.jimallan@tsbvi.edu>

Attending:
jg - Jon Gunderson
mm - Matt May
tl - Tim Lacy
cl - Cathy Laws
ss - Shawn Stableford
ja - Jim Allan (scribe)

Date: Thursday, 27th February 2003
Time: 2:00-3:00 pm Boston Local Time, USA (18:00-19:00 UTC/GMT)

SS - Tech Access, company that does web access

Introductions all around.

Agenda

Review Open Action Items
jg - discuss jg comments to xhtml accessibility. is there consensus in the
working group.
time to work on test suites at face to face.

XHTML
jg - review comments [http://www.w3.org/WAI/UA/2003/02/xhtml2-comments.html]
they make a strong statement about accessibility.
use the term "selected", may need to work (clarify) definition of "selected"
in relation to "focus" and "select"
2 new elements: proposed 'navigation list' element - designed for pull-down
menu look and feel. 'label' element associated with 'nl'. may have some
focus issues related to this.
cl - can you use this as a select menu?
jg - map elements . use as an alternative to 'map' is image not available or
not rendered. also, use in place of 'area'.
in the list section expected behavior is described as a pull-down menu
cl - is this a select menu, use the items as an option in x-forms
jg - depends how they are rendered. tables are rendered as a matrix of
cells. but can be rendered differently, linearly based on info in scope.
this is a good opportunity to reinforce separation of content from rendering
with the xhtml working group. authors need to include structure in content,
so users can render in alternative presentations. if users/browsers cannot
do this, then authors will not include it.
cl - behaviors
jg - rendering depends on actions available. active and inactive areas
need to talk about navigation lists. Sec. 508 collections of related links
should be skipable and navigable to. Nav list could be used for this.
Authors could use this to satisfy 508. allow for functionality to jump to
nav list.
cl - nothing for force authors to use this.
jg - is this the right way to approach group
cl - yes, its more confusing. you can have an href on any element, not just
activateable elements. harder to get authors to do the accessible thing.
href can now be an attribute for any element.
mm - value in doing this.
cl - from accessibility view, it is more difficult. currently, can put an
event on anything, makes it difficult to find actional items.
jg - xhtml is still in draft.
tl - had a problem with authors, make container objects (div span)
actionable, but no way to tell the user functionality exists. if it becomes
a standard there may be a way to inform the user.
cl - using javasript to make activateable elements.
tl - you can make it
mm - needs a lot more thought.
ss - this could be very difficult for keyboard users, if every thing is a
link
mm - will these show up in tab order list.
jg - uaag says they should be in tab order list. not clear if block level
element will be part of tab order. not sure how it will work.
tl - hope that it would work as it currently does.
cl - select menu, how will it work, today only select menu has a problem
like this. HPR uses control reading mode to get to menu,
mm - image with source and href, huge paradigm shift.
ss - this is getting into theory of hypertext. totally reworking what we
have had for last 10 years. will just get rid of anchor all together.
?? want to switch over
mm - not a goal of xhtml. want 2.o to be a clean break and get away from
html. getting rid of legacy elements. rethink functionality. not going to be
seamless.
ss - thinking more from user side, not author. will they see a difference
mm - user agent will change and users will  have to change. things will look
and feel differently.
jg - how do you style this. how to show that there are sublinks
mm - cascaded links will be difficult to render, no double or triple
underline, will key off of style of href. still needs to be designed.
jg - may extend bad authoring practice.
mm - it is unclean to use <a href....><img....>, difficult to differentiate.
jg - what does HPR does with nested anchors.
cl - not sure. should use outside anchor.
jg - add to test suite.
jg - image with source
cl -
mm - inline content within the object element. better than alt, can do more
with it.
jg - every image becomes an object.
mm - very important to use inline content, alternate images, links to long
description, versions of alt. idea is that alt, title, and longdesc are
limiting. using inline object text provides much more flexibility.
cl - accessibility checker will have a hard time determining is alternative
content is available.
mm - can warn them well ahead of implementation. so they can figure it our
ahead of time.
jg - content already being ported to this format.
jg - hypertext attribute - access key, keyboard bindings users should be
able to query for keyboard bindings and change the binding to meet their
needs. any comments.
cl - saying author should list the binding.
jg - no, user agent should tell user, like jaws 4.5 does currently.
requirement of uaag and to remap. no standard keybindings, w3c will not do
this, for internationalization reasons
jg - imagemap, no browser will render alt for area if images are turn off or
not available. they should provide the description of image area, which is
now hundreds of way to do.
jg - 8.9 heading elements. for authors to support structure, user agents
must provide some functional behavior. should be able to get outline view.
user agent should be able to navigate between header elements. this should
be a standard feature for all browser.
jg - add these item, to expected behaviors of user agents as part of the
xhtml spec. if documented in the spec. it reinforces the requirements of
UAAG. want to have a better defined list of behaviors.
jg - 10.2 UA should be able to skip nav links move to next element beyond.
then would satisfy 508 requirement of skipping nav elements. should have use
cases associated with each of these. another feature of w3c recommendations
is use scenarios.
mm - education outreach has several documents related to this.
cl - 508 requires skip nav link, if in a nav list, functionality would be
the same.
jg - if UA has this functionality, user would see a difference. if UA
enabled
cl - could make it look the same but act different.
jg _ right nature of accessibility. thinks that look the same but functional
entirely differently.
cl - as a UA we try to make them work the same, regardless of how they are
coded.
jg - UA can do this. its a way for authors to functionally test that they
have done something correctly. then HPR could have different function for
skipping link or nav link.
tl - leaves call.
jg - assistive technology must compensate for poor markup. map and nav list
are similar ways of doing the same thing. this is an attempt to get xhtml
user agents to think about different nav schemes. should we add to this
list.
cl - may not provide that function singled out. nav list could be just one
navigation type. don't want to be restricted. don't want the xhtml
accessibility guidelines to conflict with uaag . worried about "exclusive".
may be too restricting. HPR must meet both specifications.
jg - makes note.
jg - keyboard model of navigation. user can change default style of nav
lists. problem for learning disabled population. see static list.
mm - could be controlled in css.
jg - right, should be implementing css. not sure how to render lists
statically rather than pop-up
mm - not sure. if anything specific in css for xhtml 2.
jg - should be done through css styling property or value, display should
have a new value for nav list.
jg - 11.2 area alt rendering. area should have label element, to associate
text with it.
cl - never use label for area, but use it for map.
jg - use label to title of map element.
ss - everything supposed to be backward compatible.
jg - if images off alt text for area is unavailable. coordinates for area.
list elements can have coordinates. maybe all elements can have coordinates.
cl - can't style rendering of alt
jg - should be able to style conditional content. same styling as text
content.
xhtml linking module, forward and reverse links. user should be notified of
same, and be able to navigate to them. why does w3 care about this when
browsers don't do anything with it.
mm - mozilla implements this. an additional tool bar will pop-up for
navigation.
ja - mozilla does same for style sheets, select multiple author supplied
css.
mm - Netscape does this live, and css is persistent for all subsequent
pages.
jg - reiterate, that there should be functionality associated with link
element, as well as persistence for css selection.
jg - object. mechanism for api to pass user text styling to the object,
i.e.. foreground and background styling. for high contrast then applet will
follow user setting. no method to pass that information to object.
ss - if there is conversation between browser and object, they could
transfer information. browser could be set up to know this information and
pass this information to the object.
jg- similar to object bounding the size of the object rendering and also
pass the styling information to the object. or object could get styling
information from the user/author style sheet.
mm - need to think about it.
cl - object should inherit system settings.
jg - may not have access to system settings.
object has final say over how it is rendered, can ignore or accept system
settings.
cl - asking the UA to pass the css and system styles.
jg - active x can get system styles. dependent on Operating system.
mm - dependent on skin palette (?) gnome or kde onscreen palette.
jg - in a locked down system, dependent on what is available. no consensus
mm - able to pull values from css.
jg - can't assume css.
mm - in context of xhtml, must assume it is there. in discussion with css
folks, it is a write only mechanism for the author. don't want to derive
values for
jg- want access to foreground/backgroud and font metrics for object.
cl - css doesn't apply to an application, should inherit the system fonts
and colors.
jg - but it should, for any object use these attributes to pass to object.
should inherit browser setting, user may not have access to system settings
but can change browser setting.
ss - should be available
cl - browser itself, doesn't apply css to chrome.
jg - does in Netscape, one for chrome, one for content.
cl - so Netscape would pass chrome to object.
jg - should be either. this is an extension of width and height. should be
what is used to render html not the chrome.
cl - there are many different kinds of objects. menus group objects, many
things that are not defined on a web page or within css.
jg - no consensus.
cl - if you have a css that maps to similar settings in object - then ok
jg - only want forground/backgound font size and family. should have access
to this info and object will decide how and where to apply this information
within the object. would give applets an opportunity to style objects
similarly to xhtml content.
ss - more information is better.
jg - currently applets have no ability to restyle themselves based on user
preference.
jg - change default rendering of nested objects
ss - multimedia, if I am blind, skip the video, just sent the audio or the
transcript.
jg - browser would know what it can render, and give users option of
choosing default render.
ja - what about nested objects each with inline content. which is the
browser to render.
jg - objects should be nested to show alternate rendering. should inform the
user of options available and be able to select between them.
ss. - users could configure what to render and in what order.
jg - there is global and local configuring. first function what is preferred
default rendering - not flash or image, give me audio. or user query the
object what options are available, then choose from options.
jg - consensus from all concerning object rendering and options.
jg - table linearization.
ss - linearizing tables, can only linearize table horizontally. can't
linearize by column.
cl - can do that with HPR
ss - but not with other agents.
cl - mark up are not preventing you from doing that.
jg - if you remove mark up can't find columnar markup.
ja - perhaps use scope = col
cl - currently the browser counts cells to render columns
jg - may propose, but difficult because you can't render columns through css
without calculation. want this available globally turn off all tables not
specific tables.
jg - any objections to sending to pf and html working group.
meeting with qa group next week be sure to read relevant documents.
implementation report update IE and Opera 7,
mm - reviewing safari, they are on board. trying to get them to participate.
not complete enough to be of value.





Announcements

1. User Agent FTF Meeting in Boston, March 6-7 at all working group meeting

Discussion

2. FTF meeting agenda

3. XHTML 2.0 Specification accessibility features (Draft comments from Jon
Gunderson)

3. W3C Quality Assurance Draft Documents (for our review)

a. QA Framework: Introduction
b. QA Framework: Operational Guidelines
c. QA Framework: Specification Guidelines

4. Implementation report and test suites

Open Action Items

JA: Create implementation report for IBM Home Page reader using HTML 4.01
test suites (27 Feb target date)

MM: Create implementation report for Internet Explorer 5.2 for OSX using
HTML 4.01 test suites

MM: Check into updating evaluation for to included downloaded forms

CG: Create implementation report for IBM Home Page reader using HTML 4.01
test suites

JG: Check to see if resources are available for Coloin Koteles to continue
development and editing of test suites

CL: Review test suites for IBM Home Page reader

JG: Schedule time with QA at FTFto talk about tools to help track
dependencies between working groups and specifications

Jim Allan, Webmaster & Statewide Technical Support Specialist
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/
"I see the Earth. It is so beautiful."--first words spoken by human in
space.
[Yuri Alekseevich Gagarin, from the Vostok 1, April 12, 1961.]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/2003
Received on Thursday, 27 February 2003 16:04:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:13 GMT