F2F minutes Mar 6, 2003

UAAG F2F Mar. 6, 2003
present:

Jim Allan (scribe)
John Gunderson
Matt May
Cathy Laws
Rich Schwerdfeger
met with QA from 9-10:30

review agenda,
Today-test suites and QA, meet with EO how to promote UAAG; future
directions, view multimodal product demonstrations.
Tomorrow-XHTML 2.0 issues and discussion, future directions, meet with xhtml
working group

test suites
review and test the suites, and develop new tests.
focusing on html
need to test the apis but don't have the skills

rs: need help from Microsoft. can we automate, must test api, what dom level
do they support, where is documentation for the dom api, (p1 in UAAG), need
standard binding, need documentation for the bindings.

jg: don't have a mechanism for saying this is a required test, this is not a
definitive conformance standard.

cl: not a complete test of all functionality. many of the tests are manual

rs: responding to system response (if change to sticky keys does browser
allow it)

cl: not test cases for these yet.

rs: bring up onscreen keyboard to see if it works

jg: should we have separate tests for sticky keys or on screen keyboard

rs: yes

jg: testing keyboard and api support, add to issues list

(Ian Jacobs joins group)

ij: Microsoft contributes lots of test files for html working group.

jg: review html 4.01 test suites

ij: we should contribute tests to html wg if they don't have them. uaag has
a particular dtd. need add to issues to discuss with html wg.

jg: need a common set of tools in w3c they we could use what we need.

ij: show html wg what we do, and they can use them.

jg: qa for html 4 and earlier was not good. but each iteration gets better

jg: we need to look at the accessibility, and how to enhance the spec.

rs: do we want to include tests for plugins i.e. captions

jg: proprietary captions for each media player. have some draft test suites,
but not sure if they are on the server.

ij: not able to make the html wg meeting. if there is any way to move it
then I could make it.

jg: we will be talking about xhtml in the morning

ij: I will make that, and voice concerns.

rs: html and device independence meeting tomorrow.

jg: any strategy in xhtml meeting on Tuesday to incorporate uaag.

mm: no,

jg: will integrate ij concerns and present to html tomorrow, make them aware
of our issues. like to coordinate with pf. want us to have a plan for test
suites. any body have a problem with integrating accessibility test suites

ij: give them requirements, so they have something to integrate. give them
tests.

jg: 2 things we can contribute: requirements in the spec, and test suites
for the requirements.

Jason says specs should not specify behaviors.

ij: html as a declarative language. what does the "a" element. no definitive
behavior for the "a" element. makes for fuzzier specs. it does make sense to
say "if you are a user agent, then when you see an "a" then you should
follow user agent guidelines"

jg: qa process should clearly define accessibility requirements.

ij: authors of specs don't pay attention to behavior requirements and user
agent conformance to the spec. pdf was discussed in wcag - how much time
should we spend on none w3c technologies. wcag will not make technique
documents for pdf. will work with adobe and adobe will house the techniques
documents. global goal to improve accessibility. politically sensitive
topic.

rs: adobe has svg players, it is a w3c spec.

ij: we work with svg wg on accessibility.

jg: should we be working on svg test suites

jg: this is a resource list. we don't have people time to do this.

ij: should put it on the issues list, svg still active. Chris lilly is chair
of svg

review svg test suites

ij: nov. 2002 test suite for svg.

ij: go through svg suites and see what we want, and what is missing.

rs: do they have dom api test, so you have access to alternative text., is
it keyboard accessible, can the user slow down the animation.

ij: review spec, say this is where uaag requirements fit, then look at tests
and modify accordingly.

jg: wcag have tests for svg

mm: no

jg: part of issues, is what is an accessible svg document.

mm: Charles m-n wrote a document about accessibility of svg.

ja: we are concerned with player/browser behavior, spec can have
accessibility requirements, but it depends on the user experience of the
particular implementation.

jg: need to find who has test suites, what can we steal, what is missing.

ij: start with html

jg: what are issues with the test suite for html,

IJ leaves

mm: nominal test suite document for svg, linked from wcag.

jg: qa has a matrix of all test suites. assume that developers of svg
viewers are using test suites.

rs: have authoring tools wg looked at our stuff, do the tools support
alternative text creation. mm is liaison to atag.

jg: mathml has test suites.

rs: need built in accessibility and bold on accessibility. when we started
UA we had problems with browser and assistive tech integrated. we separated
them to move on. industry beginning to build accessibility into the devices.
hard to put jaws on a cell phone, etc. flash problems, need to build 'at' in
to the product, makes it more cross platform. problems with xml for 'at'
vendors. what to do with name spaces, and what behaviors to apply.

jg: mozilla, uses rdf to define behaviors of user interface.

ja: xml can display on the screen with css so it looks like html but 'at'
will not know what to do.

jg: test suites: svg, xhtml, mathml, smil (still problems),

jg: do we have people to review these specs for accessibility.

action Matt May to review svg spec. end of march.

jg: mathml

mm: netscape 7 has native support

jg: will have students look at mathml

action jg will put smil info on the website.

mm: talked with adobe, macromedia, etc. to work on ATAG

jg: getting more working group participation. we have people on the call,
want to get qa people from Microsoft involved.

rs: get someone from IBM testing to participate.

jg: need to recruit more people, perhaps meet at apple for safari and
quicktime.

jg: also trying to get konceror to come, travel problems.

jg: working group members, are getting smaller. 2 directions: move to qa,
and next version

rs: get other working groups to add members responsible for accessibility to
uaag. must have someone with ownership to join. then they can go back to the
group with a road map. something that pf group should do also.

LUNCH

uaag - eo meeting

Introductions

Jim Allan
Cathy Laws
Chuck Leuterneau
Sean Henry
Andrew Arch
Charman Corcoran
Matt May
Judy Brewer
Jon Gunderson
jg: want people to hear about uaag and implement it.

demo resources and materials

test suites (html 4.01) and implementation reports (last call and rec)
explain test suites and demo (120 tests)
Eric Vellaman, Helle B., Natasha, Alister join the group

4 levels of rating (complete, almost complete, partial implementation, no
implementation)
jb: need higher level information.

jg: still need implementation for multimedia players, want to highlight
things that are completed and inform developers of things that still need to
be implemented. give developers specific information regarding
implementation. then they may consider it as a bug to be fixed. goal is to
integrate these test suites with other suites in w3

jb: wai domain perspective: uaag was in development for a long time. may be
a disadvantage. considers one of best specifications in w3 with additional
information, conformance model, test suites, etc. it is ideal for promotion.
very good material. very strong testimonials

some promotion needs
building more awareness for browser vendors and 'at' vendors
awareness in disability community to raise user agent accessibility as an
issue to developers. strong potential partner. doesn't know enough about how
good the specs are
awareness in purchasing area
cl: Canada has online procurement tool kit, uaag is used as a test for
purchase

jb: should link to Canada info on the policy page.

promotion of implementation of uaag
online curricula for uaag similar to wcag,
in house (w3) assistance explaining uaag
discussing list of deliverables from EO charter

how people with disabilities use the web
organizational policies
implementation planning resource suite
parallel doc - using user agents to increase accessibility (from authoring
tools)
etc.
have a range of examples to use

cl: wcag slides might be useful for test suites.

ja:similar to henter joyce html test pages for screen reader functioning

jb: brainstorm more.

jg: want to work with eo to develop materials. working on test suite
implementation report. want the test suite integrated with html test suites,
and others. also looking at future specification and uaag interface. see UA
as support role to EO

jb: EO sees itself as a support role to UA

sh: UA give idea what the vendors are saying. EO doesn't know what vendors
are saying.

jb: some companies say we can say nothing public. need to look at the
testimonials and read between the lines. companies will not commit publicly.
others say will incorporate, but can't tell you when, others say will
implement, but all confidential. in general-vendors say it is extremely
implementable. problems with development cycles.

jg: opera is using test suites for evaluation.

jb: Microsoft will not comment anything publicly. but have use the suites.

sh: you guys have it great. most people we talk to about content don't
understand accessibility.

jg: disability community is asking for 508 but not uaag.

aa: what about Europe, Australia

jb: most developers are in US. feedback happens in US

aa: purchasing point of view, use uaag as a guideline requirements for
purchasing.

jg: many disclaimers in uaag. we are not a conformance report. there are too
many add-ons that change functionality. opera and ie support keyboard, but
opera has more, but no way to test and reveal that within our reports. may
need sub tests reports to highlight differences between browsers.

mm: don't want to always hammer on developers that they are doing something
not right. development cycle is long term. ATAG has been out since 2003 and
still no authoring tool that claims conformance. development cycle is 18
months to longer. must be careful about saying you are not working fast
enough to fix the problems.

jg: have global test comparison, but not on a checkpoint comparison. want to
broaden uaag accessibility to authors by showing them how behaviors can
change authoring practices.

cl: authors say you want me to put this stuff in but I can't test it.

jb: plan some messages or themes per quarter or years, in the media.
accessibility is important. standards harmonization is useful.

themes that are useful--

pwd blames themselves or the 'at' not the browser. get the user agent into
the process. 'its the user agent and you are not stupid'
its easy to check out a user agent. it is not rocket science to test browser
for accessibility.
sh: many people who could benefit from features don't know about them.

cl: web developers benefit from UA, use hpr or jaws to test the code. when
things don't work, is it the code, or the 'at', I point them at the
compliance document to see what is or is not implemented.

jg: implementation report. we know developers are reading, but they won't
comment. in conformance report developer can say which parts of uaag are
supported and which are not.

jb: shortime left....brainstorm....then summarize before end.

aa: parallel doc to selecting authoring tool. include interoperability.

char: quick tips (condensed version of uaag),

jb: who would you be...developer, user, etc.

char: anyone, use for

sh: need to expand mozilla to include netscape, galleon, etc.

natasha: help me understand what are the issues when using a browser that
pwd will have. testing my code in different browsers, what is a code issue,
what is a browser issue.

cl: people want to know not which item is not supported, but want
information in English plain language.

alister: reinforce idea that it is not always the screen reader is broken,
but check the browser.

jg: need to be able to do functional testing or novice.

jb: trouble shooting tree, for problem solving for accessibility...browser,
style sheet, 'at',

hb: choosing authoring tools, how to overcome problems when tool does not
conform to guidelines, how to work around.

sh: user materials for people with disabilities.

jb: EO is lay oriented, most pwd, have some level of trust of wai work, but
don't have a grasp of the overall task. looking at plain language materials
that explain thing. like what the guidelines are.

sh: problem could be x, or y, or z.

cl: do documents state the audience out front

jb: no, specific documents have specific audience, but must allow for
non-audience access. many different combination of audience for each
document.

jb: developer of user agents are important. how do we reach them.

sh: what do the developers need to know, they have a long dev. cycle.

jb: internally, marketing, cost control centers, dev. team must negotiate
priorities. feature by feature decision. need a business case for auxiliary
benefit of accessibility.

ja: doc for pwd that tells who to talk to in a company about a problem, use
the test suites as talking points, bridge to get the language across.

cl: it is a balance. many criteria. what are web authors doing.

ja: shows hexagon

jg: functional testing. what kinds of markup are present on a webpage that
make it accessible--tool development and making decisions about
accessibility. tool is for manager, how to weigh accessibility vs. cool.
empower manager to view scale of accessibility for large scale development.
can share those resources .

Summary
people want information about what browser is better. want developers to add
features
empower UA purchaser/selector to make a choice-decision, resources and
choices
something oriented to pwd to help understand guidelines and
interaction...YES needs refinement
something to help the implementer, develop business case type materials,
useful for a developer team to help weigh priorities.
discrepancy report, educate people about discrepancies. try to synchronize
goals of users, ua developers, and 'at' vendors. promote synchronized
implementation.
also promote through content developers. they will impose requirements on ua
developers
break
what do we need to focus on now

plugins - svg, mathml
voice xml - remote control of accessibility features
pervasive devices - passing preferences to new devices (CCPP, LIP(Learning
information Profile), etc.), user passing preferences through server. ccpp
designed for mobile space- put additional functionality and preferences on
the server. need support the device and the preferences.
need to get browsers to support ccpp protocol (in second last call) -- apply
as update to UAAG
are there things we can do to help 'at' aggregate information , namespaces,
schema, rdf resources-and what is revealed to the 'at'
privacy issues - cc/pp
dom css api, what is the composite style sheet (interaction between portal,
author, system, and user settings), techniques for css cascading.
javascript, semantic information (rdf) purpose of event, need to address in
future. bind device specific control to device independent function. list of
events (9.6)
DRM - managements of rights, to override drm for disability access.
multimodal-interoperate 'at' with accessible user agent or content that
talks
what are the requirement for user interface for speech rendering,
modularize uaag. update modules.

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.459 / Virus Database: 258 - Release Date: 2/25/2003

Received on Wednesday, 12 March 2003 11:41:47 UTC