EOWG -- 22 Oct 2010

<scribe> Scribe: Doyle

<scribe> ScribeNick: doylesaylor

Shawn: We have three things on the agenda. Ian sent some comments on the WAI, ARIA I updated the documents. Anyone have comments on the slides today? If not I don't want to go into that. Will postpone till the face to face meeting. I would like to take time for

WAI-ARIA review - discuss comments from an education and outreach perspective

<shawn> http://lists.w3.org/Archives/Public/w3c-wai-ig/2010JulSep/0068.html

<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010OctDec/0010.html

Shawn: We are looking at WAI ARIA review, link to email and Ian's comments.
... Thank you Ian for reviewing the WAI ARIA to discuss.
... From the beginning. First comment is about marking up the abbr. Any reason WAI would not be expanded. First question. Suggestion WAI should be expanded, any reason not?

Ian: no

Shawn: next question is every instance on the abbreviation/acronym, what is the best practice for marking up throughout the document. You can mark and abbreviation without expanding.

Ian: In a document where every fifth word is WAI ARIA it is a bit distracting.

Shawn: how about the comment that assume WAI should be expanded as well. We suggest not marking abbreviation throughout, at select places at the beginning because it is visually distracting? Unless compelling otherwise?

Liam: at the beginning of sections?

Ian: I was suggesting that. Keep linking into the sections at each minor point you could justify doing, but best at the sections.

Shawn: most of the places where it links into it. In real use of this in the real world. The percentage of people linking into here would know already or from reading.

Ian: It is less important in the lighter sections.

Shawn: can you write up for the next pass Ian?

Ian: I will. I will take the transcript notes today.

<IanPouncey> ACTION: Ian Reccomend that WAI is expanded in the <abbr>, and that the abbrevation is only expanded once in each section to avoid visial clutter [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action01]

Shawn: The next one is on the introduction.

Ian: You may have to scan on the previous one to see if that is appropriate.
... Is that paragraph clear at that point in the document?

Shawn: thoughts on the one question is...do we it reasonable to assume they have read something else? Or not?

Ian: It is reasonable read something before hand, it doesn't mean that they should read it before. We need to think about how to make the wording, taking the definition with the rest of the paragraph.

<shawn> "Please see the WAI-ARIA Overview for links to related documents for other audiences, such as the WAI-ARIA Primer that introduces developers to the accessibility problems that WAI-ARIA is intended to solve, the fundamental concepts, and the technical approach of WAI-ARIA."

Shawn: WAI-ARIA says see the primer we say early on to make sure they link to the primer. So people have some basics. Maybe even, looking at the sentence before it. (see IRC)
... I will put an action for Ian. Link is wrong, add to comments to fix that.

Ian: What should the link be?

Shawn: It should go to take off the trailing slash.

<shawn> ACTION: ian: link to "WAI-ARIA Overview" from http://www.w3.org/WAI/intro/aria/ -> http://www.w3.org/WAI/intro/aria or http://www.w3.org/WAI/intro/aria.php ( take off teh trailing slash [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action02]

Ian: that works better.

Shawn: I will fix.

<shawn> ACTION: shawn fix http://www.w3.org/WAI/intro/aria/ -> http://www.w3.org/WAI/intro/aria [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action03]

Shawn: I was looking at the overview, to see the explanation in there.

Ian: It says roles to describe progress. Simplified really.

Shawn: can we say it explains basic terminology?

Ian: Not so much terminology, it introduces the tools WAI uses.

Shawn: Do we think in the previous paragraph, where it says this is for developers. Please see ARIA for...

Ian: The first question about is this point valid or not.

Shawn: you could say people should know what a role is and go somewhere else. But if it is to explain roles here we should go ahead and do it.

Ian: should we go ahead?

Shawn: if we can.

Ian: two aspects of a role, like a role is brief description taking from the document describes types of widgets. Does this break the sentence too much?

Shawn: It does sort of. You could put another sentence before and after.

Ian: ok

Shawn: point them somewhere else to go, or a simple way to do it?

Liam: I am equivocable. I would not want it, but I could see people I train would.

Shawn: what about making the definition clearer? Reading and don't know what it is then click on the definition and explain what it is. The comment is to explain better in the glossary what roles are.

Ian: I will put as an action item.

<IanPouncey> ACTION: Ian Suggest improvement for role glossary item (http://www.w3.org/TR/2010/WD-wai-aria-20100916/terms#def_role) [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action04]

Shawn: the next in the email is the non-disabled user?

Ian: reading from the email. (reads) In some ways the comment disabilities is a bit irrelevant. Widgets used to describe to them.

Shawn: Any disagreement with that?

Ian: If we agree can we have some time to rewrite that.

<IanPouncey> "To a non-disabled user, it may look and act like a collapsible tree widget, but without appropriate semantics, the tree widget may not be perceivable to, or operable by, a person with a disability because assistive technologies may not recognize the role."

Shawn: Is that the idea to get across?

Ian: could you put into IRC?

<shawn> To a person using a visual browser, it may look and act like a collapsible tree widget, but without appropriate semantics, the tree widget may not be perceivable to or operable by a person using a screen reader or other assistive technology that does not recognize the role.

<shawn> To a person using a visual browser it may look and act like a collapsible tree widget, but without appropriate semantics, the tree widget may not be perceivable to or operable by a person using a screen reader or other assistive technology that does not recognize the role.

Shawn: (reads the new version) I think you can take out the first comma too. Good catch I really like the difference not a person about disabillity or not. Very nice.

<shawn> ACTION: ian: suggest change to: "To a person using a visual browser it may look and act like a collapsible tree widget, but : hout appropriate semantics, the tree widget may not be perceivable to or operable by a person using a screen reader or other assistive technology that does not recognize the role." [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action05]

Ian: Not too much to concern ourselves with, a little bit technical to explain a bit different.
... with the figure the paragraph before describes the issue. I feel it is a lot of information, specific accessibility which the text isn't.

Shawn: a perfect example where you want a long description, you want the long to include H1 and H2 list to communicate what is a image. You might want to say where the general gist is explained is part of the text, but the details should be available elsewhere but not in the alt for people who don't want the details. Any other comments?
... (reads from email from Ian) Comments on that.

Jennifer: agreed

Sharron: agreed.

Shawn: suggest wording? Or clear, for example you should use an H1 element instead of. Take a second to word it.

<shawn> 'For example, you should use an h1 element in HTML instead of use the heading role on a div element.

<IanPouncey> ACTION: Ian Figure 1 descriptive paragraph lacks the details contained in the image. Recommend that the image description is expanded somewhere (not in the alt attribute) - good case for longdesc. [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action06]

<shawn> 'For example, in most cases you should use an h1 element in HTML instead of use the heading role on a div element.

Ian: an H1 element should be used instead rather than not a heading element. I am standing back a moment. The heading element is outside the and think about how to use the H1.

Shawn: Lets count on them to know more about the technical parameters. and say suggest they should do it, and make it stronger, clearer that usually you should.

Ian: that sounds good.

Shawn: Liam?

Liam: why do we have a heading role?
... most be a reason to mark up the H1?

<IanPouncey> ACTION: Ian Make wording more strongly in favour of using h1 instead of div with role of heading [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action07]

Ian: it is a reason is a primary heading, rather than a page to jump to. Essentially like a skip link programmatically.'

Liam: defined as a heading for a section of the page?

Ian: Yes, mark up as a role heading for sub sections you wouldn't give them a role of heading. No way to make that sort of granularity.

Liam: ok.

Ian: use case if it requires a role of heading it takes them both.

Liam: the seperate clase role of section head. Rather than Heading. I am looking at the heading was there to get you out of the whole.

<shawn> shawn: is heading role clearly defined and differentiated from <hx>?

Ian: you could say that about WAI-ARIA.

Shawn: Is this clearly addressed in the documents? Can I get an answer to that?

Ian: a good question. You should know.
... it is not specific about that. It does make the point around the document is specific to a semantic marker. In section seven it does say throughout. The fact of the elements and hopes it works.

Shawn: Are there other points like this? When should I use headings. Still use H 1 2 3, when should I use the heading role to be clarified. Maybe not in WAI-ARIA but in the primer or somewhere else like that. Take a look at that?

Ian: it is worth looking for.

Shawn: I am strong propenent of the technical specification of only the including only the information needed to the technical information and other explanations are in separate documents.

Ian: in other documents entirely. It would mean keep the intro and then keep 3 4 5 6, and move everything else into a separate document.

Shawn: yes, I have to look again at how things are split up. The deal is once this is done it cannot be changed. Once the technical explanation is set in stone, whereas the primer is notes that can be updated. It makes sense to me only things that need to be set up in stone. One so that the technical explanations is short and sweet. And two put in the primer or the road map later what is needed to change.

Ian: we have explained they should have read something else to understand this?

Shawn: that is the other argument.
... I won't dwell on but FYI to take up.

Ian: the whole document makes clear that WAI-ARIA says that. Agreed?

Shawn: yes.
... going to number 4 important terms anything to H3?

<IanPouncey> "Examples of assistive technologies that are important in the context of this document include the following:

<IanPouncey> screen magnifiers, which are used to to enlarge and improve the visual readability of rendered text and images;

<IanPouncey> screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;

<IanPouncey> text-to-speech software, which is used to convert text into synthetic speech;

<IanPouncey> speech recognition software, which is used to allow spoken control and dictation;

<IanPouncey> alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;

<IanPouncey> alternate pointing devices, which are used to simulate mouse pointing and clicking."

Ian: something we talk about a lot.

Shawn: the first thing we want to do is say please add a link to how PWD use the web. We should look at the whole definition of assistive technologies.
... how about? Shadi look at this in the context of how PWD use the web soon. How about a place holder comment we will have a on assistive technlogy defintion of terms. Any comments to share now, or otherwise to discuss in November.

Ian: yes.

<IanPouncey> ACTION: Ian to inform PFWG that we will have definitions of AT and a link to the EO How PWD use the web document that they can use soon. [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action08]

Shawn: we will need to look at more carefully. Any other user agent?
... any other comments on that?

Doyle: no way

<shadi> :)

Shawn: Action on that. Shawn bring WAI-ARIA important terms.

<shawn> saction: shawn: bring WAI-ARIA AT "important terms" to EO for additional disucssion (and point Shadi to it)

<shawn> ACTION: shawn: bring WAI-ARIA AT "important terms" to EO for additional disucssion (and point Shadi to it) [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action09]

Shawn: Anything else on that. Role models character issues. 7.5 to discuss.

Ian: yes
... to me that was not clear enough.

<IanPouncey> "WAI-ARIA roles, states, and properties are intended to add semantic information when native host language elements with these semantics are not available, and are generally used on elements that have no native semantics of their own.

<IanPouncey> They can also be used on elements that have similar but non-identical semantics (for example, a nested list could be used to represent a tree structure).

<IanPouncey> This method can be part of a fallback strategy for older browsers that have no WAI-ARIA implementation, or because native presentation of the repurposed element reduces the amount of style and/or script needed.

<IanPouncey> Except for the cases outlined below, user agents MUST always use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, rather than using the host language semantics.

<IanPouncey> "

Ian: does that actually tell me that?

Shawn: needs clarification. Suggested wording?

Ian: if we have some suggested wording that would be better. I would say we drop the reference to older browsers or change to a bit more encompassing, vers 6 is not going to help you. It is not just about browser. What do others think that is trying to tell you?

Jennifer: if you use, since older browsers and older API support WAI-ARIA is the gist of what I got.

Ian: the first two sentences make sense but I get confused with that last two sentences in the paragraph. I don't know if we need that? Especially in a document targeting developers and also user agents.

Shawn: I am not sure what this is trying to say.

Ian: that was my problem what is the paragraph for?

Shawn: maybe say we don't understand what you are trying to get across. Maybe this or this, we would be happy to talk to an editor to do another re-write of it. It is very useful to say we don't know what you mean, but perhaps it might mean even if we don't have something to say, to help them understand where we get confused or don't understand.

<IanPouncey> ACTION: Ian The meaning of section 7.5 (particularly 1) was unclear to us. Can this be re-written to explain more clearly. Perhaps the last 2 sentences of p1 make this less rather than more clear. [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action10]

Shawn: Thanks for that Ian. Anyone else have anything?

Ian: I would agree that even if this was a case for other documents this would easier to read to the core points. I was reading in the entirety the only way to discuss is in multiple sections but is a very useful document.

Liam: it is a fairly difficult thing to explain.

Ian: I understand even though I am used WAI-ARIA reading that, and I am still confused.

Shawn: the current editors have different hats from a technical writer that could simplify the language would help?

Sharron: I think that is a great idea. When Lisa was on this committee she had a knack for making our work accessible. Is that appropriate to say to them?

Shawn: yes we can say this is how this written. How it is presented. How much is hard to understand period, whereas what could be re-written to make easier to understand.

Ian: I didn't like it is primary for developers and talks quite a bit mixed into the text about user agents do, takes away from the focus.

Liam: know the user agent is quite useful for the developer.

Ian: for example (reads) ... Is that useful to developers?

Shawn: the developers need to know the user agent does that but not more.

<IanPouncey> "5.2.8: The DOM descendants are presentational. User agents SHOULD NOT expose descendants of this element through the platform accessibility API. If user agents do not hide the descendant nodes, some information may be read twice." - is this detail neccessary in this document

Liam: there may be room for more examples, like if you have an element in DOM but that shouldn't strip the semantics from everything below it. You might have a strong element in it. You would need to read about not inherenting the parent element to the presentation.

<shawn> ACTION: ian - consider whether we want to ask them to reconsider what information is in the spec (/TR/wai-aria/) VERSUS what is in the supporting Notes. [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action11]

Ian: absolutely, not the meaning of this, but just jumping around, it is not telling developers what to expect from user agents, but more like to vendors.

Jennifer: It seems more like an organization issue.

Liam: agreed. Given to the content it is appropriate to a single audience.

<shawn> ACTION: ian - consider suggesting that they focus /TR/wai-aria/ on developer audience and leave out instructions for user agents (since have a different /TR/ doc for user agent) [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action12]

Ian: yes, but an awful lot of information here. The different properties, stick into the back of their mind and see how that works. But very dense.

Shawn: see the actions I posted in IRC.
... You can figure out what your comfort level with that. Give specific examples maybe an editor could take a pass, but say generally this takes a long time to get through, and is complex, and could we make it easier to digest. And here is some examples.

Ian: I will come up with some egregious examples. An aside, they talk about what user agents should do, and API should do. You are left to find out what actually happens in the real world.

Shawn: One thing we can suggest an ideal suggest situation. A good database or resource where user agents do this thing. If I was a developer I want to go to a site that supports X.

Jennifer: there are some that do this great.

Ian: responding to HTML 5 elements there is stuff out there.

Shawn: that is not get into the TR document, we can link to but not in. The resources links to the notes which can be changed.

Jennifer: change all the time as AT and user agents catch up.

Shawn: In my configuration the elements are metallic and green. They have lighted dotted underlined. Comments? Visually representation of in page link or definition, they have light dotted underline, and highlight? For my eyes it goes black. WCAG goes purple.
... WCAG goes purple and ARIA didn't.

Ian: ARIA goes green at some point.

Jennifer: shouldn't they all be the same?

<IanPouncey> ACTION: Ian Suggest using consistent styling / markup across WAI documentation [recorded in http://www.w3.org/2010/10/22-eo-minutes.html#action13]

Shawn: yes, and they are ARIA marked up in Italics. We say suggest that the style sheet including things like (style guides also) including how they are visually set up and be consistent with WAI documents as possible. Leave to them to deal with that. We have a chairs meeting next wednesday. Also references, I will check and see, are they marked up with site or other?
... It is, because they are marked up with 'site'? What do you think about that?

<shawn> consider un-italics "cite"

Jennifer: too much of it is hard to read?

Doyle: that is my impression of that.

Shawn: Ian if you can write up next week. We can send from the whole of EO.

Ian: I will try to bundle, I will try to make clear which ones I am doing.

Usability-Accessibility document

<shawn> http://www.w3.org/WAI/EO/Drafts/access-use/accessibility-n-usability.html

Shawn: The latest version.
... let me go through and tell you what has changed from last week.
... Feel free to look at on any level. On this draft a problem lets change now. Less significant suggestions for a re-write then. We might want to suggest things to do now, and others for re-write. In the first paragraph we re-wrote some, and the second paragraph we changed totally.
... comments on the introduction. I will point out what changed from the last time. In the introduction in the fourth paragraph is new. Under the whole understanding accessible, the first paragraph has changed a lot on that one. Under usable accessibility has changed. ...That's the main things that changed since last week.
... Go through section by section. Overall comments?
... Shadi and I felt we were getting close.

Liam: looking really good. One suggest in the second paragraph of the introduction. Include user for everyone.

Ian: make them the accessible for PWD and for everyone?

Shawn: we want to say both. Usable for PWD and for everyone.

Ian: we don't want to stop at just being accessible, we want usability as well.

Shawn: let me note that. I got the idea.
... other things on the intro? What about the understanding accessibility section?
... anything in the last paragraph. Sharron?

Sharron: Now I look at this section and I think it is too long.

Liam: I think it reads well. It is easy to read. I disagree with Sharron.

Shawn: I was looking at examples.

Sharron: you don't think this is too long?

Liam: correct.

Shawn: Sharron if you have suggestions for tightening up please send them. The next section understanding accessibility and UCD.

Ian: worth expanding UCD in the title?

Shawn: probably I don't know.

Sharron: It is in the first sentence?

Shawn: in the first paragraph.

Jennifer: partly an issue with the audience they would know what it is.

Shawn: I don't like headings. Some people will know it and some won't.

Sharron: go ahead and put in the title, not that long.

Shawn: other comments?

Ian: makes sense when you use if everyone knew what UCD meant you wouldn't need this document.

Doyle: expand it.

Jennifer: expand

Liam: abstrain.

Sharron: i don't feel strong either way.

Shawn: anything else in that section. Second sentence is new. we got a comment don't minimize. Anything else about that section?
... next section usable accessibility including usability research and practice. We want to talk about how much to cover in the real people section and then the next section is revised.
... comments?
... do we need to say more about real people? In previous version we had more text on that. Do we want to repeat that.

Doyle: no

Liam: abstain

<shawn> WCAG 2.0 Framework for Flexibility and Adaptability

Shawn: you will get another chance to look at this. What about the whole section about adaption where we struggled with the most. Framwork for Flexibility and Adaptability. We directly address this information in the community.

Sharron: the second sentence the word should be 'must'. And also one of Liam's themes the idea it is not PWD the problem that are not designed right is the problem. To emphasize here we have the rules the standards, so that the PWD fades away to be replaced by you didn't do this???? Maybe this paragraph we have this framework the very concept of the disability is changed when you get on the web.

Liam: I have a small one. Second sentence starts (reads) suggest change make it easier to pause. Include 'supporting documents to include'. I would ruther have the subject as the first word. My complaint is that it reads as a phrase. A small suggestion.

Shawn: to me supporting documents for WCAG is too complex.

Liam: you can use supporting documents instead of WCAG.

Shawn: ok.

Ian: My suggestion for this section. Reads as if WCAG 2 is a framework for accessibility and usability.

Shawn: agree

Liam: shorter a framework for accessibility and flexibility.

Shawn: the thing is earlier we are talking about other guidelines as well.

Liam: you do that with the first word which says paragraph.

Shawn: I'll try, the other ones do just as well. But easier we say we introduced all of them but we focus on this one. Anything else the last section. Where do you feel like we are at on this? One question with some documents they are not very controverial. We publish done, but with some we want broader review before calling draft. More time for EO to look at, and more people to look. Do you feel comfortable as final, and draft.

Liam: I think you would get more interested comments to say final document.

Shawn: Shadi and I will be working on this. So if you have comments now or later go ahead and send. We will be asking for more soon.

Sharron: how long in draft?
... we could say a month, then we address all the comments and publish. We had something for May we had out for a draft handled the comments and published it. That is out of draft. we cycled pretty quickly. From public draft to final went pretty quickly. Could be five weeks.

<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010OctDec/0007.html

Shawn: today is the fee deadline for the face to face meetings. Make sure to pay today. The price will go up. do today. An agenda out now for the face to face, and How people with disabilities use the web. Please comment.

Ian: I have been trying to review but it is perfect so far. It is excellent.

Shawn: thank you have a wonderful weekend.

- DRAFT -

EOWG

22 Oct 2010

Attendees

Contents

WAI-ARIA review - discuss comments from an education and outreach perspective

Usability-Accessibility document

Summary of Action Items

Scribe.perl diagnostic output