W3C

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

11 Apr 2013

See also: IRC log

Attendees

Present
Jim, Greg, Jan, jeanne, Kim, Simon, Eric
Regrets
kelly
Chair
JimAllan, KellyFord
Scribe
KimPatch

Contents


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

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/04/11 18:46:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]