Minutes: UAWG April 11, 2013

from http://www.w3.org/2013/04/11-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference 11 Apr 2013

See also: IRC log  http://www.w3.org/2013/04/11-ua-irc
<http://www.w3.org/2013/04/11-ua-irc>
Attendees
PresentJim, Greg, Jan, jeanne, Kim, Simon, Eric, Judy
Regrets
ChairJimAllan, KellyFordScribeKimPatch
Contents

   - Topics <http://www.w3.org/2013/04/11-ua-minutes.html#agenda>
      1. render/chrome <http://www.w3.org/2013/04/11-ua-minutes.html#item01>
      2. review RDWG Mobile A11y Report (Apr 23
deadline)<http://www.w3.org/2013/04/11-ua-minutes.html#item02>
      3. comment on 1.4.2 level too
high<http://www.w3.org/2013/04/11-ua-minutes.html#item03>
      4. Testing Suite - Jan and Jeanne (start working on this
now)<http://www.w3.org/2013/04/11-ua-minutes.html#item04>
      5. Open Action Items<http://www.w3.org/2013/04/11-ua-minutes.html#item05>
      6. wrapping up UAAG20<http://www.w3.org/2013/04/11-ua-minutes.html#item06>
   - Summary of Action
Items<http://www.w3.org/2013/04/11-ua-minutes.html#ActionSummary>

------------------------------

<trackbot> Date: 11 April 2013

<allanj> trackbot, start meeting

<trackbot> Meeting: User Agent Accessibility Guidelines Working Group
Teleconference

<trackbot> Date: 11 April 2013

<jeanne> http://www.w3.org/WAI/UA/2013/uaagSCbychrome-render.html
render/chrome

Jim: we had a conversation today on getting more input for the group and
somebody at the W3 thought that a lot of what we needed was more people
from the rendering engine side of the equation for WebKit or blink or
whatever else is out there and they were going to talk to Apple to

<jeanne> http://www.w3.org/WAI/UA/2013/uaagSCbychrome-render.html

there is some rendering, opponents to this type of stuff but most of it is
finding a way for the user to configure to tell the browser what to do.
Today we went through every success criteria and said which of these is or
mostly chrome and which are mostly rendering and came up with a list: 79
mostly chrome and 28 mostly rendering

Jim: additionally I wrote to David Boulter at Mozilla and did some research
on user interface and chrome trying to see if these sorts of issues show up
in bugzilla and they don't
... setting up the user interface – if there are long descriptions and how
to render them etc. – that's a little user interface issue and not for this
Mozilla list. So I said where is the user interface list, where is the
chrome list for Mozilla. I have not heard back yet
... compounding the issue it's difficult to search for chrome
... this is our first pass so we can get some data to get more bodies in
here – if you have comments you can send them to the list

Jeanne: I'll put it in the wiki as well

Jim: they were all pretty much both, they all have some sort of rendering
comp opponent, and we have notes in there. We decided that almost
everything was both, it's just that some are more than others and this is
our first past – the ones that are mostly rendering are marked rendering,
the ones that are mostly chrome are marked chrome but the understanding is
that they are all both
review RDWG Mobile A11y Report (Apr 23 deadline)

Jim: This came up in the CG meeting yesterday. Simon?

Simon: mobile web accessibility, we have a number of papers submitted,
finally got to the seminar. From that seminar came this note and what came
out of it – future of mobile accessibility – trends and future direction
... it's been through our internal review process. We wanted to put it to
internal groups before we put it to public release for comment

Jeanne: it's a very impressive report, Simon

Simon: it is a quick turnaround because we're trying to not lose pace on
it. If there are things that are missed or people need more time they can
do it as part of the standard public comment. We wanted to make sure we
didn't miss anything the groups really desperately wanted to be in there.

<sharper> public-wai-rd@w3.org

Simon: any comments that you might have, send to that list.

Jim: anybody have time to review?

<sharper> http://www.w3.org/WAI/RD/2012/mobile/note/ED-mobile-20130326

Jan: I'll probably do it

Jim: I'll probably take a look at it too
comment on 1.4.2 level too high

Jeanne: one of my colleagues was looking at UAAG as part of another project
I was specifically looking at the text customization area, and she noticed
that 1.4.2 zooming text, we have it at level a period she felt strongly
because none of the browsers do it and it's not a blocking issue – people
can still get to the information, it may be more convener lest fatiguing –
she thought that...
... having it be a level a was way too low. Since no one currently does
this it would be a blocking issue for all of the browsers.

<allanj> current 1.4.2 Preserving Size Distinctions: The user can specify
whether or not distinctions in the size of rendered text are preserved when
that text is rescaled (e.g. headers continue to be larger than body text).
(Level A)

Greg: many browsers do do this, don't they? They preserve size, but you can
overwrite this with the stylesheets

Jim: so you're saying the mechanism would be how to write a user stylesheet

Jan: the mechanism is just to use the zoom

Greg: Zoom preserves the size distinctions, which is great unless you want
the text to be really big. But you can turn this off with user stylesheets

Jan: I see it's the whether or not part of it

Greg: at the moment I think it's worthwhile, because as the two examples
show

<allanj> scribe: KimPatch

Greg: let's take the counterexample. Let's say someone needs to have the
text as large as the screen in order to read it. If the only choice is to
have headings be twice as tall as the screen, is it usable to them or not?

<allanj> Jim: so a sufficient technique for a UA to meet this would be to
allow the user to write a user style sheet

Greg: user has low vision, needs to use the magnify thing to set fonts very
large in his browser so that they are about 75% the height of the screen so
he can use his low vision to read it. I have seen people doing this. If
when he does that the headings all become twice as large as the screen, he
really can't read them then. Is that okay? Would you consider the browser
to be usable by him or not?

Jeanne: you still have the option of using user stylesheets to change it

Greg: that's what I'm saying, that's how you comply. But if there is no way
to do it, does it comply

Jan: is your point that we have another level a requirement – so the only
method is already covered by another requirement?

Greg: I can see your point if we're sure that user stylesheets will always
take care of that. For HTML they probably do I don't know about other
technologies.

<allanj> jim: Guideline 1.7 is all about user style sheets

Greg: if I go into Firefox and choose to not allow headings the same size
as fonts. Word is another example – can use stylesheets to use one font for
everything. while I think it's important if you want to downgrade it. I
just wanted noted that yes there are examples of it being done.

Jan: I think we should keep it and note somewhere that it can be done with
style sheets. Because stylesheets can do lots of stuff. And this is an
important use case.

Jeanne: we actually do link to stylesheets as part of the resources

Greg: given the abilitie to force the use of single fonts and draft mode as
examples of how can be implemented today

Jeanne: it's a tricky thing, because she actually thinks that there aren't
magnifier user who does this. She's a magnifier user herself and she
doesn't know anyone who would do this.

Greg: so she runs the magnifier with – allowing the headers to be
considerably larger than normal font

Jeanne: Yes

Jan: I think it only comes up when someone has to run a font at 75%

<allanj> Jim: jeanne, or were you envisioning a single radio button to make
all the font sizes the same

Jeanne: like Wayne

Jim: and he uses stylesheets

Jeanne: if you think we aren't going to have implementation problems – she
thinks there will be implementation problems

Greg: so you can't change built-in styles

Jim: a single button to do that I think that's what she was thinking of
... I have my font set to 18 and headings are bigger – everything goes up
from there

Greg: I chose don't allow webpages to choose their own fonts –
tools/options under content colors click advanced, check off allow pages to
choose their own fonts, and in minimum fonts drop-down list box choose 24,
and it looks like headings same size

<allanj> *ACTION:* Jim to discuss 1.4.2 level with shawn and jeanne.
[recorded in http://www.w3.org/2013/04/11-ua-minutes.html#action01]

<trackbot> Created ACTION-817 - Discuss 1.4.2 level with shawn and jeanne.
[on Jim Allan - due 2013-04-18].

Jim: testing. One of the things Judy was talking about this we could start
building test suites for test cases now and start cobbling together the
HTML pages or whatever to start testing and not waiting for last call when
we have to get the testing done anyway.
Testing Suite - Jan and Jeanne (start working on this now)

Jim: Jean can you expound on what we need to do with testing

<Jan> ATAG2's testing doc:
http://www.w3.org/WAI/AU/2013/ATAG2-10April2012PublicWD-Tests

Jeanne: looked at what atag did: see what we should standardize on – the
format, the language that we would use, and sat down and wrote all the
tests.

<allanj> UAAG 1.0 Test Suites - http://www.w3.org/WAI/UA/TS/

Jan: to add to that, there are a couple of useful sections: decisions to
make before testing – level, technologies, resources needed – these are all
the things you should have any computer when you start. There's a list of
seven different resources that you should have. aAso discovering
applicability, going through all the controls

<allanj> WCAG 20 test suites - http://www.w3.org/WAI/GL/WCAG20/tests/

Jim: considering repurposing tests

Jeanne: we don't have access to all the WCAG tests – they are not in a
format that we can get to
... we can refer to them, but the only place we could get to them is
extracting out of the WCAG document. The tests are in university databases
we don't have access to.

Jim: use the draft ones

Jeanne: but do we want to

Jim: anyone have a desire to start working on these
... can we start this in a wiki

Jeanne: I think it's harder to get them out of the wiki
... if there are people who want to start on this, start writing some,
figure out how we want to do it and standardize our language and format and
how the page is set up

Jim: is there a certain skill set – organized, attention to detail and
things like that?

Jeanne: it's who would like to take the lead on testing, and experience
helps – knowing how to break it into pieces, test what you want to test and
not extra things…
... if we all work together on it will go fast. Especially in a face-to-face

Greg: I will help out

Jan: I will be there too, but I don't want to run it

Jim: I will help out

Kelly: I will definitely help out, but if possible I'd like to not run it
Open Action Items

Jim: next time Jean publishes a document when she gets back we will remove
all the dones and all the was – was this was that (previous numbering's)
... I was looking at WCAG test suites. Did ATAG do things that way?

<allanj> ATAG test suites: http://www.w3.org/WAI/AU/2012/ATAG20tests/

Jan: ours will say need a checker, but what type of checker you will need
depends

Jim: we have to test the chrome part and the rendering part

Jan: one of our say something like investigate the user interface and or
documentation to try to find that feature – you don't know if it's going to
be about nor what, or where it's going to be.

Jim: and then you document that –

Jan: no, just a pass and move on

Jim: documenting everything is a massive amount of work

Jeanne: we want to make sure we prioritize the amount of work so we get the
information we really need and were not collecting anything extra

Jim: that we are not writing accessibility manuals for every browser

Jeanne: it's one thing to think about having the browser manufacturers do
it, but it's another thing to realize that I'm going to have to do it for
all the products we are testing – we're going to have to test them all
ourselves. Think about it that way. What do I want to have to record

<Jan> http://www.w3.org/WAI/AU/2013/ATAG2-10April2012PublicWD-Tests

Jan: newest one
wrapping up UAAG20

Jim: Greg and Kelly, you've done a lot of testing

Judy: we have to ask ourselves how much progress are we making, scope,
milestones and give it a clear representation to the W3C advisory committee
... the working group has been working on different early versions of the
spec for a very long time. Milestone wise it's been kind of missing some of
those. The updated charter that is going to be put out pretty soon along
with other charters from the other working groups needs to have a timeline,
but not just a timeline that you think is realistic – that's not the only
goal. The question...
... is to get the spec done so that it can – there's a lot of things that
need to happen after the recommendation is finished. Help promote getting
the thing used.
... one thing is the initial draft milestones that Jeanne had showed me I
was concerned about because it looked like it was a schedule that was still
very prolonged. And it looked like it was a schedule that actually had a
lot of time in stages that maybe could be done shorter and maybe no extra
padding in time in stages that might particularly need a lot of time. They
were I think 22...
... months in the last call period which is extraordinarily long for that
... WebKit – right now I'm hearing that that can be sometimes two years,
I'm hoping it's not for most of the things you need. From Jeanne I'm
hearing what the best way you may work. Face-to-face can compress time
needed. Then what's the process of how you are looking at comments and
processing issues and with most groups the groups respond to things that
come in partially internally but...
... largely externally and when I look at the comment traffic on the list,
it's very low. So it doesn't look like there are a lot of comments coming
in. So I'm wondering what about the efficiency of the comments generating
within the group. There's a lot of rearranging going on. Do you think you
are rearranging in a way that is matching which actually needed by the
implementers. We don't want...
... a perfect spec for a perfect spec sake. We need something that can be
taken up. Don't mean to offend, but are there ways we can think about with
the workflow.
... you are doing good work. We wanted to be implemented
... levels – sometimes that's tricky if you have a lot in one level. But it
seems like the rationale for that is maybe fairly sound. There were some
things in terms of conformance levels that I was kind of curious about. I
think the main thing that I wanted to talk to the group about was that we
need to have with the new charter that the groups behind and we need
milestones attached to...
... that, but milestones the look reasonable in terms of the completion
time. I'm actually pretty sure that the milestones that were in that first
draft would get pushback on from the advisory committee or just W3C
management. So unless there's either really really good justification for
why the schedule can be made more efficient or an updated one that takes
advantage of maybe different work...
... approaches that you can take…

<allanj> current draft charter:
http://www.w3.org/WAI/UA/2013/draft_uawg_charter20130314

one other thing I wanted to mention was the test suites, it could be that
you could have some people in your group working on that, and getting that
moving. Optimizing what is run in parallel with.

Judy: End of thoughts…

Jim: we started the discussion today on testing and what was involved in
looking at the old test suites and those sorts of things and lots of people
are willing to help. And we were hoping to get someone to lead the charge.
We haven't found that person yet.

Judy: I experiences is harder to ask if there is someone to lead the
charge, who is interested

Jim: Greg and Kelly and Jim

Judy: Eric, stage the working group is at right now, it may slow them down
to do a lot of detailed work on the success criteria itself, but if you
turn that energy toward writing tests, it sometimes helps prioritize the
type of feedback. If it turns out that some of the provisions written by
the working group is untestable that's critical information that's very
concrete
... the people that are stepping up in terms of testing, Jeanne and Kelly
and Jim, that's quadruple tasking…
... my comment to Eric, for detailed – turning that into a test suite is a
very good match, my two cents

Eric: I appreciate that – I'm going to look at my various commitments and
make sure that I am able to take on – do what I commit to do

Judy: Greg, I think you had done a pretty major walk through the document
when you came in if I'm remembering right. I don't know if you're still
doing some of that.

Greg: I did make it clear that I would help out the extent that I can on
the test preparations – I have done a lot of – but I won't be able commit a
huge amount of time to it. I will be able to at least add some advice and
expertise based on my experience

Judy: do people have questions about timeline – do you think I'm smoking
something when I talk about trying to make it more efficient, pushback

Jim: we spent a lot of time because our first one they were so way off
base. Previously we were finished three years ago and that obviously hasn't
happened. It's the nature of how many people we have in it just takes
longer. Our big fear is that we are not going to get any comments because
nobody cares

Judy: I think it's a possibility right now. I think they should care but
I'm very worried about the engagement issue. I think that Jim and Kelly and
Jeanne and I are going to keep talking about that piece but – every working
group is different – good group because work well, but it would be a shame
if it's out of sync with what the developers need. And that could directly
impact the...
... timeline...
... because it seems like it's less clear prioritization. Rewording but
still not get closer to what the implementers can benefit from.

Jim: there may be a split there, because we've always approached it from
the user side as opposed to the user agent side. The emphasis on the user,
what the user needs as opposed to what the agent needs.

Judy: you have great confidence in what the user needs, but you need it to
be used by the user agent developers. I think that's the problem.

Jim: it's a concern for us that were going to go to last call and get
absolutely buried, or they're just going to walk away.

Judy: that's probably the most important thing you can be doing – there are
many ways to get engagement.
... more specifically I was wondering we were talking about some strategies
– is it possible to get people in more face-to-face meetings would you be
able to get the things in a much better rate, or maybe even distributed
face-to-face where you have two or three clustered locations, calls between
them. Are there any ways to increase the rate of issues that youre walking
through or is...
... everything taking – every issue will take a third of a meeting. Usually
there are ways to prepare more, do more of it off-line. And it's worth
looking at those kinds of things.

Jim: we seem to do really well at face-to-face and get vast quantities of
things done. Although less so on the extended calls although they are
fairly efficient.

Kelly: when we have looked at the timeline, we were thrilled by them. And
we did get a sense that you would give push back. In your ideal world –
what timeline do you think you or the W3C management would be reasonable.

Judy: how many issues do you have left – I had heard multiple times that
you were pretty nearly done with her issues, I don't know how many you have
– I know you have some challenging problems including the distribution of
stuff to levels and not having a test suite yet, not having the exit
criteria…

Kelly: some number that you have in the back of your mind that you think
wouldn't get pushback

Judy: how many open issues besides the big issues – how many bugs or
individual little issues do you have left – is it a finite number and if so
what is the number?

Kelly: pretty low

Jim: less than 20

Judy: what's your average closing rate on your bugs – getting a sense that
it's just a few per meeting

Kelly: pretty low because we've been dealing with conformance

Judy: when you're not having to engage with the elephant in the middle of
the room what's your closing rate on bugs

Kelly: on a good day two or three per meeting

Judy: best rate, sometimes they can do 10, sometimes they get hung up on
one as well
... if you were in one place for three days could you knock off all 20 and
maybe work on conformance
... 20 bugs and still those other big elephants, that's for five months. If
you could do the 20 bugs in three days with reasonable enough solutions and
put them out for review to others in the community including implementers
and make meaningful progress on your big issues you've just saved four or
five months
... in trying to figure out the timeline it makes sense to think about not
only what you have in your plate but how to approach it. Not just quality
work but also out for review…So may be that you need to organize some parts
of the work differently.
... thank you – best wishes – thank you for everything you are doing and I
look forward to hearing where it all goes

Simon: I think it's really going to be difficult to get face-to-face is
organized very quickly with regard to travel arrangements and all those
things that we're supposed to be doing and going to a place. But what I
thought might be more useful is if we just say were going to look at the
actions that seem to be a motivation – we just do a blast on one week and
get through an hour and a half...
... each time. And then after a week were done with the issues that Judy is
talking about. And then they aren't around our neck and we can go back to
conformance

Kelly: I think what Jim and Jeanne and I should do is look at all the
issues and really think that what we think is left and really come up with
that inventory of what is left to do here.

Jim: we have a lot of elephant eating to do because we have the levels and
we have conformance and that sort of stuff. But as far as other bug issue
with things I think we've whacked most of them – there might be some little
things running around.

Kelly: we should just do a sanity check – I'll do that
 Summary of Action Items *[NEW]* *ACTION:* Jim to discuss 1.4.2 level with
shawn and jeanne. [recorded in
http://www.w3.org/2013/04/11-ua-minutes.html#action01]

[End of minutes]

-- 
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