Minutes from UAWG telecon, 27 May 04
mm Matt May
jg Jon Gunderson
aaronlev Aaron Leventhal
earl Earl Johnson
kyle Kyle Yuan
jessie Jessie Li
peterkorn Peter Korn
jg: Matt and I did a tutorial at the WWW2004 conference. I linked to the presentation today. It's being captioned.
jg: We have an evaluation underway for Mozilla. At future meetings we can go through checkpoints that we couldn't rate.
jg: Test suite system is all Web-based now. We'll be able to create tests and update evaluations. Working on SMIL/multimedia test suites.
jg: If anyone is interested in helping, we're looking for people to help with that. We have a contract with Colin Koteles, so will probably be updating the test suites this summer.
jg: Also planning on something for SVG.
jg: Questions about test suites?
jg: In the agenda.
peterkorn: We've done a lot of work with Bill Haneman on SVG accessibility, and how to add info to SVG spec.
aaronlev: We've been doing similar things for HTML.
peterkorn: This is beyond that. Grouping elements, etc.
peterkorn: In spirit.
jg: Relationship is that you can have dynamic SVG. Peter, you sound like you're describing the objects.
jg: There's been some work in the SVG spec now. Peter, you've found holes in that?
peterkorn: A couple of years ago. Bill was working on Batik (SVG Java tool) before coming to accessibility group.
jg: Would be good to discuss for a future call.
jg: Would also be good to bring that info to PFWG.
jg: And good to have SVG test suites out there as it gets more popular.
aaronlev: SVG accessibility would be key because of things like Rational software for describing relationships, etc.
mm: And Visio, which exports SVG.
jg: Might be more likely to get accessibility info than from proprietary alternatives.
earl: Isn't there an update for UAAG?
jg: Not yet. If you have any ideas, we could discuss them.
jg: Important thing is to get people to meet our current requirements before we create new ones.
jg: Matt has discussed using UAAG for mobile technologies.
mm: People I talked to have been working on the same things we were working on several years ago (how to create good content, good tools, etc.), and I suggested we might be able to give them something usable based on UAAG.
jg: Goal is more concrete directions.
jg: Keyboard models.
jessie: Can anyone else add tests to the suite?
jg: Right now it's in beta, so we limit what people can change. Later, we will add password protection so authorized people can change things.
earl: The testing code will be there also?
jg: In the next couple of weeks.
jg: I have Gnome 2.4 running.
peterkorn: You should have 2.6.
jg: OK, I have 2.6.
peterkorn: Community 2.6 doesn't come with accessible Mozilla, but will come with Sun's version of Linux.
peterkorn: Last version of accessible Mozilla posted?
kyle: 1.4. Long time ago.
jessie: We have 1.7.
peterkorn: Can that be put on mozilla.org?
kyle: We need more tests for 1.7 before we can put it on mozilla.org.
jg: Would like to talk to you about getting a stable build, Jessie.
peterkorn: The trunk may be several weeks behind Sun's work. But what you build from the trunk should be much more recent than 1.4.
peterkorn: If you build it, it won't be more than a few weeks behind.
jg: We built on Gentoo Linux.
mm: My Gentoo bulid is giving me Gnome 2.4 and Mozilla 1.6.
jg: Does Sun have a distro with 2.6 yet?
peterkorn: Working on a system that automates the Gnome building process. If you buy the older Sun Java Desktop, you can build it on top of that.
jg: Was talking with Aaron that a common set of extensions for Windows and Linux, we'd have a broader set of tools for looking at structured markup.
jg: I see this as the first step, and from there we need to focus on what meets people's needs. Right now we just look at lists of things, but in WindowEyes and JAWS you can find headers with a single keystroke.
jg: What can we do to help Sun in the implementation?
peterkorn: We should play with UIUC's extensions and how they work with Gnopernicus.
peterkorn: When I played with it a few months ago, they looked like they provided a number of interesting things, though through indirection because of the level of abstraciton.
peterkorn: Could have two or three items per line on an 80-cell braille display. Would make the user experience more efficient.
aaronlev: When Mozilla is exposing itself through MSAA or ATK, it has to look at each layout object and ask what it is, because it can't use element name to know what it is. Has to look at layout objects. Should we be exposing these as tables?
aaronlev: I've heard that CSS shouldn't affect behavior, but it's affecting navigation behavior, since keyboard users are going to navigate them differently.
jg: HTML markup, or XML markup?
aaronlev: I don't know that people do it, but it's possible.
aaronlev: Would be good to know whether CSS affects accessibility information.
aaronlev: Would be good to think about when you do your table stuff.
jg: Tables are tough. Interesting to see how they interact with screen readers. In WindowEyes...
aaronlev: It works.
jg: Are you able to expose the table markup?
aaronlev: We put that on the name of the table.
jg: Using headers?
jg: When I'm in a data cell, how do I know what headers apply?
aaronlev: MSAA doesn't know that.
aaronlev: We did it the way IE did for compatibility with other screen readers.
aaronlev: ATK is taking advantage of advanced table markup. If there's any accessibility vendor that's seriously into this, that gives us more of a reason to do it.
peterkorn: We have bridged StarOffice acc. info to screen readers. That's another option to get Mozilla working with screen readers. Would be significant work, but we can do it again here.
peterkorn: I'm not suggesting "we" = Sun.
jg: Other things we can help with?
peterkorn: Testing and feedback. Lively discussion on gnome accessibility list on what blind users want.
peterkorn: Some users with programming skill would be quite useful.
jg: We have two blind users at UIUC that are programmers.
jessie: We will put Mozilla 1.7 on mozilla.org when we can.
peterkorn: Will you send an announcement?
louie: Difficult to judge whether state exported by Mozilla is correct. In some cases, the state is correct, but interaction with Gnopernicus has problems.
jg: Meet again in 2 weeks? June 13?
aaronlev: Don't know that we need it every 2 weeks. Maybe once a month.
jg: June 24/25? Same time?