Shawn: I want to remind you to
get a reservation because hotels will book up. Registration helps us to
have an idea about who will come there also. There is a nominal
fee to cover things. There is a 40 Euro per person per day fee.
Can register now but pay fee separate.
... You can pay the fee in October. Questions? about F2F and
hotel?
Sharron: what are we expecting for EO. Quorum sized group?
Shawn: we don't know yet. We are in process of updating the EO charter. Ours is fine. We are processing all together. I will afterwards work on actively recruiting.
Sharron: The F2F feels really productive. I was hoping to get things done, and it's nice to meet folks after talking on the phone.
Shawn: Questions?
Shawn: this is the last call on the ATAG review last call.
<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010JulSep/0031.html
Shawn: Yeliz has a couple
comments, reads one of Yeliz's comment is about a template
issue and about WCAG design. Template issue we should submit to w3c site-comments.
...
And why not include
definition?
... the definition is a long sentence, include the one sentence
definition? Any objections to that?
Sharron: no
Shawn: the next one is about three different links to get to WCAG 2.0 notes section. Can this be improved. That has to do with the formal referencing. Comments? I propose we mention this is an issue, but make it up to them to solve.
Doyle: I agree with that proposal.
Shawn: Next where it goes to implementing link to an authors page, any comments about two links doing very different things.
Liam: skip link....
shawn: objections to how this goes down the page and the other to a new page?
Liam: yes
Doyle: yes
Liam: move the keyboard focus.
<shawn> ACTION: write up yeliz' ATAG comments, and the [Contents] [Implementing] issue. and the in-page link needs move the keyboard focus [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action01]
Shawn: that might be a template
issue. Can be fixed easily. ATAG that is all the comments from
EO. The deadline is next Thursday but they could give an
extension of one week.
... can folks read through ATAG?
... is there anyway can find time to review ATAG in the next
week or so?
Liam: is the audiences defined for this?
Shawn: there should be a requirements document but I'm not finding right off.
Liam: that would be a lot easier. I'm not an authoring tool developer.
Shawn: two perspectives I'm counting on good input on this. That's the perspective we can have is the user and the disability advocacy and education outreach. Can leave perspective of tool developer to others.
Sharron: I can get to things in the next two weeks. I hate to ask for extension, I can do in two weeks I can do a thorough review.
Shawn: not a lot of time for EOWG disucssion, I would
ask feel free to submit comments directly. May be good to CC
the EO list. If you think it would be good to have EO
perspective feel free to submit to EO. They would like comments
before their F2F meeting. Got to them before that by the 14th
would be ok. Feel free to use whatever filter, especially the
substantive issues. We want to avoid having sent back from last
call.
... I'll tell Sylvie about this date. When she gets back from
vacation. Anything else about ATAG?
Shadi: I'm not ready tp comment on that.
<shadi> http://www.w3.org/WAI/EO/Drafts/sketchpad/excol_toggle
Shawn: two light blue boxes that look like expand all. We were talking about should the change be? A toggle, something for screen readers and visually what kind of control should that be. See the third link is a toggle. One would be enabled depending on the state. Quick reactions to that?
Shadi: a note that is not that simple programmatically. Doable but not having toggles but have a function is desirable.
Shawn: can we talk about ideal user interface first, then do reality check?
Shadi: Let's talk about the interface everything is doable. I prefer the not toggle because this is easier and less prone to bugs.
Sharron: you prefer the non toggle?
Shawn: from a programming standpoint, not a user standpoint?
Liam: hmmm. I have had to do a toggle off before, I am thinking about where to find that.
<shadi> http://www.w3.org/WAI/EO/Drafts/sites-older-users/Overview.html
Shawn: two aspects what is the ideal interface and the second is the programming issue. We may have to stand from the ideal because of resources for programming. Is the toggle objectionable from the user interface standpoint?
Liam: I think better from the user standpoint.
Shadi: from my point of view I am
not for either point, the user standpoint or programming. See
the link I put in the IRC. To the current developing
site.
... if it is really necessary from a user perspective we need
to look into, but if a small improvement let's put on the wish
list.
Shawn: I think it is optimum from a user perspective. I think it debatable that would need an ARIA change. I clicked on something to expand or collapse I would argue it is not needed. The other thing to figure out. Are these links or buttons? Programmatically. What do screen readers get?
Shadi: if it is form button we can't really change the look very easily. We couldn't use a form button, we would have to call it an ARIA button nicely decorated but a link.
Shawn: I hear screen reader users complain about links and buttons used wrong for going to a new page versus performing an action.
Liam: do a script off the ARIA button? Not a script, but a button.
Shadi: I will look into that.
Shawn: If you don't implement a toggle now, at the least change so they look like buttons even if they have no disabled state. They should not have the same look as the navigation. Can copy from sketch pad. We'll finesse for later.
Liam: I will get in touch with you Shadi later about separate solutions.
Shadi: great.
Shawn: thanks.
<shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/Overview
<shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/scenarios
Shadi: if we select scenarios of web users, page one is people using the web. Does the H1 title is the short name scenario is and the long name people using the web? objections to that.
Sharron: why the difference why not use the short name make them the same. Use the short name in the place of the long name now?
<shawn> all of them currently:
<shawn> "Overview" <h1>How People with Disabilities Use the Web: Overview
<shawn> "Scenarios of Web Users" <h1>Scenarios of People Using the Web
<shawn> "Accessibility Barriers" <h1>Accessibility Barriers on the Web
<shawn> "Web Browsing Methods" <h1>Web Browsing Tools and Approaches
<shawn> "Accessibility Requirements" <h1>Accessibility Requirements for Websites and Tools
Shadi: it was like that before. The long name describes the page better for the page. Short name might be more useful.
Liam: I think the short one is a good label.
Shadi: moving the long title as well?
Liam: I think that I prefer the short to the long in both cases.
Sharron: me too.
shadi: ok anyone for the long ones? Shawn?
<shadi> "Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization"
<shadi> "Scenarios of Web Users in How People with Disabilities Use the Web"
Shawn: one thing I am aware of is with a lot of our suite case. I am looking at especially with short titile and have the long title maybe as a subhead. to have with using the web. If I land on this subpage. In the current design. There is very little tie in with how PWD use the web. Not highlighted anywhere except in the title. I can't tell if these are autnonomous pages, or strong sub pages in a suite.
Shadi: I'll think about. Scenarios of users in how people use the web.
<shadi> "How People with Disabilities Use the Web: Scenarios of Web Users"
Shawn: doesn't work in this one.
Shadi: using a colon of how people use the web?
Shawn: visually I would like that. On another page I'll look. Maybe smaller. Semantically I would want to hear first everytime. Maybe second. Maybe for marking and getting around that would fine.
Shadi: let's try your idea and see how that goes. They have the title front loaded. Ok, unless objections, using colon in the H1 of sub pages.
Shawn: and maybe style smaller.
<shadi> ACTION: shadi - add "how peoplw with disabilities use the web:" in the <h1>s [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action02]
Sharron: that would work.
Shawn: are you comfortable using the shorter? Put in the first sentence?
<shadi> "Disabilities and Barriers"
<shawn> [[ * "Accessibility Barriers on the Web" I like it, actually. Could do something like: Barriers on the Web for People with Disabilities" but that has issues. Oh, right, the page is largely organized by disabilities. What about something like "Accessibility Needs and Barriers on the Web" ? ]]
<shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/scenarios#shopper
Shadi: I think it is there. I am
fine with moving the H1. I have a question. Look at the
accessibility barriers page.. Previously called disabilities
and barriers. There were comments about is the disability is
the barrier. I tried to use disability barriers doesn't work
that well. If you go to scenarios of web users. On color
blindness. When you select disability it says color blindness.
Barriers and disabilities. The different groups impacted
... what do we go with?
Shawn: I put into IRC accessibility needs and barriers? Brainstorm category.
Shadi: it might just fit. With the left navigation?
Shawn: It wraps.
Shadi: that's fine.
<shadi> "Accessibility Needs and Barriers"
<shadi> "Accessibility Needs & Barriers"
Shawn: with our terminology hat on. Accessibility needs and barriers, or disability needs and barriers?
Shadi: yes.
<shawn> "Accessibility Barriers" -- "Disabilites and Barriers" -- "Accessibility Needs & Barriers"
Doyle: I like Accessibility Needs and Barriers.
Shadi: if you go to the link Accessibility Needs and Barriers, you will find physical needs like color blindness.. Does that work?
shawn: I don't know what I think
of accessibility needs. I am a bit uncomfortable with that in
some cases. I like it better disabilities. Let's keep
mentioning for people to think about.
... the terminology and how that might play in different
regions and what.
<shadi> ACTION: shadi - change "accessibility barriers" -> "accessibility needs and barriers" [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action03]
Shadi: Let's go with accessibility needs and we can ask questions when people review the entire thing. Ok?
<shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/provisions
Shadi: Let's go to the last page of the disability requirements. They were organized under perceiveable, what is operable. Explain that ahead gets long before you get into the document. As a trial I tried to increase the headings using WCAG terminology, to clarify what is meant by. Instead of perceivable, like information perceiving, ...Kind of like the main headings of the page. Below some requirements listed. How well do these headings work?
<shawn> not really like "Perceivability"
Shadi: more helpful or confusing to use those headings. They are kind of jargony.
Liam: is Perceivability a word?
Shawn: I don't see in my dictionary. I don't like changing from perceiving to perceivability. Some people will take a while the H2s is perceiable operable, understandable, robust.
<shadi> "Perceivable - information and user interface components"
Shadi: how about a hyphen to make it stand out.
Shawn: that makes it standout but not quite understandable.
Liam: I think using the hyphen would be wrong there.
<shadi> action shadi - change to "Perceivable information and user interface components" throughout
Shadi: yes, for now I'll take out the perceivability, and Shawn help with the design.
<shadi> ACTION: shadi - change to "Perceivable information and user interface components" throughout [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action04]
Shadi: other comments on those four titles. Imagine Perceivable, Operable, Understandable and Robust content, or something along those lines?
<shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/provisions#alternatives
Shadi: we will discuss those sub
headings at a later stage. The next point to discuss one or two
of those. one two, Three and four have been edited according to
the previous discussion. Let's look at the first text
alternatives.
... what do people think about that?
... comments?
Doyle: I think I would keep it simple.
Shadi: what about what you think about the text itself? Someone lands on this and describes to the developer what are text alternatives.
Sharron: I'm confused by the phrase they also functions as keyboards equivalents?
Liam: the idea we get a problem to get across is it is not a description but an alternative to describing the visual.
Shadi: I am aware of that. Are there specific issues. The description might be Harry Potter, it is not an alternative for that. I see your point.
Sharron: maybe functional equivalent?
Liam: meaning equivalent. If you have a button, but what you are getting is a button, a functional aesthetic equivalante. The idea of instead of. A good point about description of a video is not the same thing, but text alternatives is not the right alternative.
Shadi: let me take a stab at that. If that is done how do the bullets work. Where you say buttons, I say labels. They are labels for them. Back to your questions. In the first sentence I try to clarify. Would that work, or the content be updated?
Liam: I think the bullets are good. With that up front they would be great.
Sharron: I think it would be good.
Shadi: I will note an action.
<shadi> ACTION: shadi - explain that text alternatives are *equivalents* to the function or the content in the first sentence [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action05]
Shadi: Sharron made a point they serve as an alternative to keyboard equivalent?
<shadi> "text alternatives serve as labels and help keyboard users"
Sharron: a big leap for someone who is not familiar. To say something like functional, or explains the purpose, makes more sense to explain keyboard equivalent.
Shadi: I will note to explain better about keyboard uses. Other comments/
<shadi> ACTION: shadi - explain the leap from "text alternatives" to keyboard equivalents [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action06]
Liam: how about aesthetic
alternatives for visual experiences.
... I am thinking of aesthetic for the sake of beauty, rather
than summarizing.
<shadi> ACTION: shadi - "serve as aesthetic alternatives for visual experiences" [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action07]
Shadi: I will add that as well. What about the approach in general.
Sharron: in the introduction I think it better to keep simple.
Shadi: the question is the new person who is non technical does that serve a point to explaining it?
Doyle: I think it works pretty well for newbies.
Shadi: ok, let's go the next one. Is that self explanatory hopefully. What do people think about that?
Shawn: I don't get why you used 'where feasible' sign language is an alternative that doesn't fit as feasible.
Shadi: the motivation is not to scare people away. If someone was new I would have to provide for all they would freak out.
Shawn: maybe what you say, in the intro examples of alternatives for audio and video, you mention not being a requirement for everything said nicely.
Shadi: I'll think about it. Thank you.
<shadi> ACTION: shadi - consider "examples of alternatives for audio and video include:"; remove "where feasible"; and add something in the blurb below [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action08]
Shadi: other comments on
this?
... except for live broadcast well written transcripts can get
you quite far.
<shawn> "Alternatives for audio and video are required by people who cannot hear or who cannot see the content." - > "People who cannot hear need alternatives for audio, and people who cannot see need alternatives for [important visual information] video."
Shawn: something like that to make active voice to make clearer.
Shadi: ok.
<shadi> ACTION: shadi - consider editorial suggestion above [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action09]
Shadi: Anymore comments this?
Shawn: let's make it clear, write up is the easy basics. This introduces the idea and links to more thorough coverage of it.
Shadi: right. I have felt they are too short, maybe short and sweet, but I wanted to make sure others are ok with that.
Shawn: If you think of how short our attention span is. It becomes too long for people to read.
Shadi: let's have a look at the
next one. Title Content can be presented in different
ways
... This one still enables to facilitates because it separates
presentation from content.
Shawn: I don't know how that might become but some more examples for that until we decide what we are decide about doing that.
Shadi: ok, other comments?
Shawn: maybe the first sentence to make more clear in order for users to change the presentation developers need to...something along that line?
<shadi> ACTION: shadi - consider "In order for users to be able to change the presentation, developers need to" [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action10]
<shadi> ACTION: shadi - use active voice [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action11]
Shawn: doesn't work with the second two. I was thinking about over all to use more active voice. headings lists and other structures are properly coded. Sequence of content instructions are independent of any presentation. Word smithing stuff.
Shadi: yes if the agreement is on the wording of. Look at the next as well content that is easier to see and hear? A bit more complex one.
<shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/provisions#distinguishable
Shawn: with the first bullet people would take would not convey information, flip around to say that positively. Limit the chances for people to read that you can't use color.
Shadi: the fun of writing that is how people interpret anything you want.
<shadi> ACTION: shadi - "Color should not be used as the only way of conveying information or identifying content" -> turn into positive, such as "when color is used, there should be a redundant method..." [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action12]
<shadi> ACTION: shadi - remove "shoulds" [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action13]
Shawn: distinguishable content is easy to see and hear, for example, take out the should and say they are...
Sharron: yes that is good.
Shadi: what about the blurb
below?
... feel free to send in some word smitthing to the list. Is
this the right amount information to get the idea about this
requirement.
shawn: yes.
Sharron: yes.
Shadi: Let's go to the next point on the agenda. The question of the page overall, is that the right amount of expanding and collapsing. When you land on the page the very first is collapsed. One suggestion is to expand. Like that what kind of expand collapse,
Doyle: I'd like to see one expanded.
Shadi: hmm.
... for instance, the first section expanded. That would push
the content way down.
Shawn: one issue is we were trying to we had table contents at the heading. we are trying to use the heading for table of contents. Especially the status box.
Doyle: well a short illustration maybe?
Shawn: when you expand something what do you understand?
Doyle: I like the shortness of unexpanded. to see everything. If I was new I wouldn't exactly know what it means.
Shawn: as expanded bullets, or headings. What is the action to expand subpoints.
Doyle: I feel like you don't have to expand the sub sections.
Shawn: good to have the expand collapse on all three of those?
Liam: I think it depends on the document. Is that worth expand or collapse at that level. Editors discretion.
Shawn: if you look at the scenario, under each sub point there are anywhere from three to nine?
Sharron: hard to make a fast and rule.
Shawn: what does it feel about those four examples?
doyle: the inconsistency might be a problem.
Shawn: we do need to come up with that is consistent. I had a feeling to see if people had the same. No comments move on?
Shadi: maybe the expand collapses could be under related sections. Whether that wondering which goes to the next issue. Related sections are expandable as a whole. I'll have a look at that.
Shawn: for the technical specifications is really short. Especially you want to highlight you want to highlight there is more. If you expand collapse you require the click to get the information.
<shadi> ACTION: shadi - move expand/collapse in related sections up to the <h> level [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action14]
<shadi> http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/2009/provisions#standards
shadi: ok. Basically the issue we
have a lot of terminology on this page. For example if you go
to on the Accessibilithy Requirements page. go to the
Accessibility Standards section. In that paragrph you find some
definitions and links that are definitions which link to
somewhere else. On WAI resources definitins at the bottom of
the page is an in page link to make it look different. In this
case to a different page, but within the suite. My
questio
... is this the correct implementation? In that one paragraph
is text alternative and screen readers, and text alternative
takes you down, and screen readers takes you somewhere else. Is
that clear enough from a user perspective?
Liam: I think it is clear enough.
Shadi: what about the amount of terminology is linked. At this stage it might still be jargony. Too much linking or better too much than too few?
<shawn> i am a bit uncomfortable with the same visual indicator usually going to a terminology section within a page, but sometimes going to a new page...
Liam: because it is essential if you can skip. If you understand you don't have to open.
Sharron: I agree.
Shawn: I am bit skeptical to go to another page sometimes I would have to process that. To see how much of an issue that is.
Shadi: I will continue doing as I am doing to come back and see if that is clearly an issue.
Shawn: a brainstrom we could consider when it activated another visual implementation of when it goes in page versus out of page?
Shadi: do I need to add a title to the link?
Shawn: no.
Shadi: when the screen readers say link text alternative...?
Shawn: if inconsistently used and implemented and providing information that users aren't getting I don't understand why you would.'
Shadi: to indicate a different kind of link. To clarify this is a different kind of link.
doyle: I am for that becasue of what I see deal with.
Shawn: I think a question for others.
<shadi> ACTION: shadi - consider adding title="definition" to the definition links [recorded in http://www.w3.org/2010/08/27-eo-minutes.html#action15]
Shawn: really quickly running through the agenda...
Shadi: maybe for everybody, a lot of stuff reviewed, we hope to wrap up fairly soon.
Shawn: it is ready for comment. sometime in early September will ask for your approval to publish. Comment now would be best.
Shawn: everyone must complete the survey.
The slide sets Ian sent
in one change, the CSS are avaialbe poke at with different
browsers feel free to review now.
... for the first bullet we want to see how CSS works for
different browsers. If you see something in the content bring
it up. The second bullet is the business case. We have a fairly
complete early draft is ready to pick apart on all levels -- from overall how it works and is organized through to detailed wordsmithing.
It is ready for scrutinization. I wanted to get more
feedback pick apart the slide set as much as you want. Same
thing with the third bullet. Feel free to pick apart at any
level.
... WAI ARIA is planned to publish as a last call. If you see anyting now that might get fixed before publication. Good to go ahead if you see something.
Per my email yesterday, We expect this pace to continue in all of September and October. Over the next few weeks plan time for EOWG work.
Thanks!