Shawn: we have one agenda item
today. To look WAI-ARIA. From the last call, "How WAI develops
guidelines through the ..." Under the WAI site under guidelines
and techniques the last link in that section to development
process.
... that is the state of things.
Wayne: mostly this is a specification we should focus on the informative section.
Shawn: I will hand over to Wayne.
He will gather our comments and lead on this. The next stage is
candidate recommendation. How people gather the standard and
should go quickly for ARIA because this has been used for quite
some time. This is a technical specification. This call is
about the EO perspective. See if there are improvements for
those who look at it.
... let's look at the companion documents. Designed more for
developers. Focus more on the companions. But since this is the
last call this is our last chance to get comments in. Let's go
to the document. Follow the agenda item.
... WAI-ARIA technical specification working draft.
<shawn> http://www.w3.org/TR/wai-aria/
William: call for review? First link there? Wayne will discuss. Alan sent an email about.
Wayne: we want to one and two.
Where the overview area is. The readability states and
properties, and descriptions. I think that is important.
Something we can make some statements. Going pretty well.
... keep in mind like the HTML spec of CSS spec, that likeis
what we are really looking at.
Shawn: something specific to look at?
William: the tone is pretty
accessible. Some people who come to this, might not know what
these terms are. Widgets are defined, but not taxonomy.
... role Taxonomy what is that?
Wayne: I'm sure there is a
taxonomy definiton in OWL somewhere.
... let's make a note on that.
Shawn: we want to make a note of that. They may need to have definition within the standard because of how it is used in the standards. If broadly understandable so not right to have a formal definition in the glossary. The answer may not have to be put a definition in the glossary.
Wayne: A really good definition somewhere in the W3C and make a link to do that.
Shawn: we just say some readers may not know this term and they can figure out how to address it.
William: role taxonomy is what I have a problem with.
Shawn: they define it in the paragraph before.
Wayne: let's take a look at that.
William: they have roles defined. They don't have API's defined.
Wayne: How common an acronym is. Put in like API.
Shawn: defined in the definition? No.
<shawn> ACTION: introduction - "role taxonomy" may be too jargony [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action01]
Wayne: a person who wants to work with ARIA may not want to think about OWL. Might not be familiar with OWL.
<shawn> action - glossary - write out API acronym in the definition of Accessibility API
Alan: part of the problem is not intended for people like us to read. it is for developers.
William: it needed be exclusionary.
Shawn: Things we had said do
we want to educate them to look at this. We don't want to
overlap information too much. We have other documents. We have
the overview. What belongs here versus other documents. We
worked on this at the technical Plenary in Boston.
... who do we want to look at this? The target audience.
William: it's beyond the target audience is not just all who might come here.
Wayne: Our target audience will be familiar with API. Part of their lives. People who use this product. We don't have to explain to them. However, a lot of java script programmers. Write validation scripts. Move into the AJAX realm. May not be familiar with the AJAX work place. Might have part of the audience thrown off by role taxonomy.
<shawn> Changelog with table of documents, audiences, etc.: http://www.w3.org/WAI/EO/changelogs/cl-aria-docs
William: bring a fresh viewer to this. We pick out those things that are jargon.
Wayne: not jargon. Technical definition. Not intended for that not familiar audience. For writing JAVA scripts.
Shawn: that is key point. If I come in to this document. For whom this not the document they don't need to read. They hear about ARIA. They don't need the technnical specification. Make sure those significant issues land on here and need to go somewhere else. We need an effective way of pointing where to go.
William: move the primer to begining per Alan.
Wayne: integrated to the introduction.
Shawn: and the overview.
Wayne: close to the third paragraph.
Shawn: the section with '
... this is informative'
Wayne: That would work?
William: have in general in most documents we deal with. Not for a lander where they should go.
Shawn: Wayne could you
draft?
... Wayne put up front who this document is for. Points to
overview and primer.
Wayne: that works.
Shawn: Submit comments put in a rationale. That would be a lot of people will land here and shouldn't read this document but another.
<shawn> ACTION: wayne - draft suggestion for putting something up front in the introduction that says who this document is for, and points to Overview & Primer. include rationale: a lot of people will land here who would be totally overwhelmed with this doc, and they should be reading another. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action02]
Shawn: and not only shouldn't but also totally confused.
Sylvie: I have problems
understanding section is normative or informative.
... section five is normative and 5.1 and this section is
normative. You don't know which is normative. The rest of the
five is normative or not?
Wayne: section one or chapter five.
Sylvie: chapter five.
Shawn: anyone have an idea what that might be?
Wayne: that is section is normative. That sub section is informative. They have to ...
Shawn: clarify what is normative and not normative in 5. For example 5.1 which is an exception.
Sylvie: the section is not really clear. All 5 or part of 5.
<Wayne> ACTION: Wayne: Clarify the scope of normative and informative regions: See section 5 and 5.1 that appear contradictory. perhaps "This section is normative, except subsection 5.1." [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action03]
<Wayne> ACTION: Wayne related: create specific language for scope of n/i. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action04]
Shawn: If we have time it is helpful to give some specific suggestions. Wayne if you want to try something like it should say section five is normative, and but 5.1 sub section is informative. Something like that. Wording we are comfortable with that would be easier for them. They don't have to use.
Sylvie: another general question. Assistive technology is used in this document. Does it mean the same in English plural and singluar or what? As WCAG, for example, uses assistive technologies in plural.
Shawn: Wayne ask use the plural Assistive Technologies.
<Wayne> ACTION: Wayne use assistive technologies instead of a. technology for consistency for other wai docs. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action05]
Shawn: Sylvie?
Sylvie: remind them to take the plural make it agree with the verb.
Wayne: can I have a reminder Lisa?
Lisa: Much more likely to be addressed.
Wayne: very different technolgoies all communicate through that.
William: ascertain all do that?
Wayne: with the introduction are there any more issues.
Shawn: look at Alan's comments?
<shawn> Alan's comments: http://lists.w3.org/Archives/Public/w3c-wai-eo/2009JanMar/0115.html
Alan: first thing is covered already. The links to the primer. Link to the scope and best practices should be at the beginning. I thought the jargon roles and states in the first paragraph. Someone who works with user interfaces. Someone with no prime knowledge they would be lost.
Shawn: we would re-direct people who don't understand we are ok. Put the editorials as something to think about for them?
Alan: I thought the introduction sounded a little odd to me. Other people?
Shawn: we want to think about?
Wayne: Lisa is part of the target audience in the form of input validation? Not accessible when they read this is part of your audience?
Lisa: yes
Wayne: I don't remember thinking about roles and properties?
Lisa: well known in any kind of object oriented programming.
Alan: warn people they need to know that before they read this.
<shawn> ACTION: Intro section. list Alan's wordsmithing as considerations for wording. from http://lists.w3.org/Archives/Public/w3c-wai-eo/2009JanMar/0115.html [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action06]
Lisa: I thought about using the analogy terminology about using web applications in a Object oriented way. A lot of about parents and child relationships.
:-)
Lisa: not to bog down the spec with too much explanation.
Wayne: I would put in a note that javascript would not be familiar with parent child or object oriented.
Lisa: a good idea. To get them early and convert them.
<Wayne> ACTION: Wayne in first section separate procedural programmers from oo programmers. First paragraph "this is informative". [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action07]
Shawn: we nee to re-look at.
Overview, Primer, and beyond. Do those things help for the
right level of terminology?
... Properties defined has check for check box, or pop up menu.
If you don't know what state is. It is covered.
... Alan's comments put as a low priority to consider?
Wayne: editorial changes as a grab bag.
William: suggest the first sentence is more jargony. Go to a different document. I am suggesting.
Wayne: do more like a technical programming book like who this language is for.
<Wayne> ACTION: Group editorial changes into an editorial suggestions item. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action08]
Shawn: One of the things to consider. Once this is published we can't change this. Other documents are notes and can be changed more easily. What to consider you want to have here as opposed to elsewhere?
Lisa: they talk about this some, but in terms of the spec itself they resist changing now.
Wayne: different from changing a
spec. May attract a lot more people that aren't ready to read a
spec. The accessibility group is a broader constituency. There
is a greater opportunity of more people getting who don't
belong here than is normal.
... I understanding keeping a spec lean.
Shawn: I have the opposite feeling. Personally a spec should be spec. Technical and explanation should be elsewhere.
Wayne: I was just talking having the re-direction language right up front. So people don't have to bother with this. Absolutely not compromise the spec part.
William: before the introduction?
<shawn> ACTION: remind them that once the spec is published, they cannot change it, whereas they can change the other documents. therefore, consider limiting the intro and other informative info in this document , and moving a lot of that content to the other documents! [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action09]
Wayne: a little work for the audience will probably do it.
Shawn: Scope?
Shawn: best practices to clarify
who needs to be reading what document basically. With that one
Wayne, read through Alan's comments when you write up the draft
and that will integrate with what we talked about.
... Anything else on the scope section?
<Wayne> ACTION: Wayne: Integrate Alans comments on scope in intro filtering of readers. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action10]
Alan: the mention of the other
documents in the scope?
... relevant for the scope to put earlier.
Lisa: used to be earlier but this is scope is here.
Shawn: maybe just an overview?
Lisa: the abstract should point to the overview. Otherwise it would take a long time to get there. So they know early this is not for them.
Shawn: the abstract does point to that.
<Wayne> ACTION: Considering intended audience in the abstract. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action11]
William: if someone reads the abstract they know if they don't understand the first sentence they are supposed to go somewhere else.
Shawn: one thing in usability testing. A lot of people skip the abstract, and make sure to put this in the justification. We need to clarify that usability studies indicate it needs to be in both places.
<Wayne> ACTION: Justification Abstract and Introduction are both neede because of user skip behavior. Also, remember the extreme general nature of readers that might land here. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action12]
shawn: provide the justification up front. This document is part of the WAI suite. Read the abstract which is only a couple of sentences. Someone not supposed to read. Would they get lost? You see overview is an easy introduction. Or beyond you and you don't click on the over view?
William: both.
Wayne: hard for me to believe they could get so lost here.
Sharron: I think the abstract was particularly well written and clear.
Wayne: make the last sentence. Imperative or something.
<shawn> ACTION: Wayne look at last sentence of Abstract -- maybe say the Overview provides an introduction to the topic? [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action13]
william: the first sentence requires and then the list of things most people have no clue of, and immediately shown the door to an explanation.
Wayne: I will look at suggested wording of this.
Alan: The glossary says somewhere familiarity with HTML make sure you are familiar with XML definition. Need to know that to read the rest of the document. Required reading first, these two definitions. That jumped across this to the term, and won't read the begining of the glossary. Warn at the beginning of the whole document. When people click on the term. Like Widget they will jump over and not be aware they are in the glossary. Just a definition.
Shawn: integrate into the beginning Wayne.
Alan: nothing else to discuss.
Shawn: Wayne if you see Alan's comments you disagree with please reply to the email for additional discussion. Otherwise just integrate into comments and we'll review before submitting.
<Wayne> ACTION: Consider prerequisite documents XML, XHTML... in reader filter statement. Also, review all of Alan's comments in this context and send ones that are left out to the list. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action14]
Shawn: point to glossaries definitions cross way specs.
<shawn> ACTION: look at glossary definitions across WAI specs (at least) note the def of AT in the one EOWG worked on. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action15]
William: people only read glossaries as a separate item. They only read for a definition.
Wayne: chapter two is the
significant one of this.
... we are at the part that people know what XML is, roles and
states and properties. The taxonomy of where they are and how
does this read in this context?
Shawn: Lisa remind what is section two of WAi-ARIA related to the other documents.
Wayne: a nice example of a taxonomy of roles. Good definition. Puts in a context that the other technologies are used like OWL. Generally basically what it does is sets the stage for understanding for the technical specifications.
Lisa: we didn't want to bog down the front end too much. Here we wanted to lay down the terminology. This is the normative thing. The definitive document.
Wayne: even though this a specification a lot of people who don't belong. If they have a little introduction they are happy.
Lisa: consistent with some of the calls. They get and they bang out the code.
William: process question. Often say a spec and carved in stone. And informative also carved in stone?
Shawn: yes.
Wayne: enough content to read the technical to know what they mean.
Shawn: my personal preference. The spec would be almost no informative stuff in the spec except where to go further infomation. That would be a separate document. Edit that to current best practices if we wanted to and that sort of thing.
Wayne: section two in here?
Shawn: I wouldn't have in here. I understand what Lisa says about they want to hit the ground running. If there is a clear pointer to information you need to know elsewhere. I feel that is better. I would recommend moving WAI-ARIA out of here.
Lisa: maybe from the specs these are terms go to the primer.
Shawn: some people want the very minimum of what they need to do. Here is the quick view of what you need to know. In the over here is what to say. If you don't want to read a whole lot of background. Need two pages read these two pages of the primer.
William: they don't want to take WAI-ARIA out of here.
Shawn: no they aren't going to take out right now.
Wayne: I find it useful to find everything in one place. Some well known idea they put a recap there. Hard to put in something in tell them what XML is and not other. Very short and minimal and right to the point and for this audience this is very good.
<shawn> ACTION: Shawn - perspectives on informative info in specs (sent with WCAG) [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action16]
Shawn: in five years is still going to the best practice. Or say something else?
Lisa: no I wouldn't.
Wayne: I will send students
straight to this.
... I get to a spec. I would go read to the secretaries guide.
To understand the section wording.
William: send your students, and not have section two is not there you would send somewhere else.
Shawn: the section two information is very good, but does it belong?
Wayne: the specs this is not a spec but talking about grammar.
Shawn: I'm glad this moved out of
WCAG 2.
... WCAG 2 is relatively lean now.
William: I think this would help to model on WCAG dom rather than general things floating in there.
Shawn: WCAG 2 is more clear about what the additional documents are.
<shawn> action - maybe point to this as an example <http://www.w3.org/TR/WCAG20/#intro-related-docs>
Shawn: put in to point to that as
an example.
... What other W3C spec has a primer?
Wayne: CSS 2.0 has a primer. Brief tutorial for HTML use. I'll put a link in.
<Wayne> http://www.w3.org/TR/CSS21/intro.html
Shawn: Lisa and Wayne. Separate in the spec. I am looking for other W3C specs. Very few groups have published anything but the specs. Everything had to be in the spec. A culture in W3C we only do specs. To be aware of. Recently some groups have published a primer. for those who published a primer did they put the informative in the spec itself.
William: in the DOM has very elaborate stuff at the beginning.
Wayne: I think this is the middle of that. They have a brief overview and primer. This is a pretty brief.
shawn: this is included in the specification and they don't have anything outside of the specification.
Wayne: those that are written under that philosophy have very short sections on overview. WAI-ARIA has extensive overview. This document is different. This does not have extensive examples because they have the primer. I can see why they don't want to put in here. Write a suggestion?
Shawn: I think it would be
interesting to come a more shared understanding here. I feel
Wayne and Lisa lean toward wanting it in, but still open. and I
want out and I would like more input. Folks willing to go on
further.
... Lisa what is your position?
Lisa: I am going back and forth. I'm not totally convinced either way.
alan: I may be missing something. This has to stand alone. Read this document with the background knowledge. Does this have what you need to understand the document.
Shawn: dependent on who you are. Background and existing knowledge. Good point.
Alan: say at the begining what knowledge you need and stand alone on that. Describes the underlying principles and then the rest dives into definitions.
<shawn> issue: should this document stand alone to some [advanced] audiences? what info is necessary for that?
Alan: when you get to the end of this section. No attempt to educate at all. The raw specification of the properties. Maybe what comes before is necessary for everyone. It doesn't attempt to help you at all.
William: I recommend the solution of DOM you don't get specification. We are missing the document like the overview.
Shawn: we have a URI for ARIA at the lowest level. We have not thought about W3C WAI-ARIA just points to the overview page.
William: it has a history. A separate document. They make the overview.
<shawn> hummm... www.w3.org/wai-aria
Shawn: it's own activity. Why that exists. It's on activity. WAI activity and WAI DOM.
Wayne: Document model core. They talk about different document model specs.
Wayne: I have been looking at section four. 4 take out chapter 2 you would have to re-organize 4. Not someone say enroll in such and such.
Shawn: I question it is here rather than somewhere else. If you are the target audience. Using this a lot. Referring back to as implementing. Read section two once. And need to go back?
Wayne: probably not.
Shawn: that means you don't need there.
William: I think it is important because it models sections that are unreadable.
alan: the normative part is meaningless without it.
Shawn: what if each section had a
pointer to the discussion relevant to that section?
... send things like that typo in yourself Wayne.
<shawn> point: the target audience for this document will refer to it often as they are implementing it. they might read section 2 once, but then not need it again. doesn't that say it doesn't belong here?
<shawn> point: what about at the beginning of each section, it points to where in the other document is the intro material about this?
Wayne: they refer back to some of the examples in section one?
Shawn: they do that a lot. An interesting point. but not sure how important.
Wayne: let's read again to see how important it is.
Shawn: imagine this information anywhere else. If not should it be? If it is it should not be repeated.
Wayne: I don't agree with that. I think repetition is important. The tree example talked about one place.
Shawn: it might be really useful to have the tree example. Have a high view, and talk about different levels and different points.
<shawn> point: is this info in other documents? if not, should it be? if so, shouldn't we point to it there instead?
Jack: I think it partly depends
on the audience and use the information. I think the other
relevant question what sort of harm to have here and not
somewhere else?
... because this is normative it is difficult to change. Would
become dated. The other to provide information meaningful to
the primary audience in one place. Appears like more relevant
information for the primary audience and not creating more harm
to be here.
William: I refer to the usability here makes less dense.
Shawn: I am open to be swayed, though feeling strongly. Based on usability what is the best for the audience. Both points have virtues.
<shawn> wayne: here's where it could go wrong in time -- if these were adopted into the dominate markup languages
Wayne: these particular widgets were adopted from the point of the dominant market languages. Someone would need to learn as an example. This was standard behavior. The relevant mark up languages this would become obsolete.
Jack: Is this likely. They would become dominant as a normative?
Shawn: a slight chance. Look at HTML 5 what things they considered. What they ruled out. There is discussion in ARIA what should be in HTML 5
Wayne: can leave some of that to be integrated in HTML 5.
Shawn: anything else on the WAI-ARIA spec? The next step for Wayne to draft up our comments. We would go over before we submit them. Given CSUN we would not do next week. Some leeway Wayne the week after CSUN or end of March?
Wayne: the week after CSUN is doable.
<Wayne> ACTION: Wayne study the relevance of the Ch. 2 examples considering HTML 5 and other emerging standards. [recorded in http://www.w3.org/2009/03/13-eo-minutes.html#action17]
Shawn: next week we have a
tentative meeting, depends on the documents responding to
organizations with inaccessible Web sites. If Andrew gets the
edits ready. The week after, move the mobile web best practices
and see how Alan is ready for that. 23rd or 27th. Another
document to review. I will send out an email to review
improving access to government through better use of the Web.
An important one for us. W3C has an e-government
activity.
... we started in June 2008. focus on governement. We will work
more in. Comments? We are adjourned.
William: some meeting at CSUN?
Shawn: I probably won't do the call on Friday.