See also: IRC log
<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
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
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
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.
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
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
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
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Simon: the/Jan: the/ Found Scribe: KimPatch Inferring ScribeNick: KimPatch Present: Jim Greg Jan jeanne Kim Simon Eric Regrets: kelly Found Date: 11 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/11-ua-minutes.html People with action items: jim[End of scribe.perl diagnostic output]