minutes from 3 july 2000 meeting

These minutes are also available 
at:  http://www.w3.org/WAI/ER/IG/minutes/20000703.html

03 July 2000 Telecon
Summary of action items
·       Action WL Go through Nielsen's site to dig up info on creating 
groupings. esp. usability tests of certain kinds.
·       Action HB E-mail the group references on style, writing, and grouping.
·       Action WC add to AERT a technique that notifies authors when 
something they have done is not supported in a browser, ala the 
HomeSite/TopStyle method.

Participants
·       Harvey Bingham
·       William Loughborough
·       Brian Methany
·       Wendy Chisholm
Regrets
·       Michael Cooper

Agenda
We've been talking about how long a block should be, but what is a block? 
Lets discuss some more, starting with Michael's proposal (thanks Michael!)
How shall we track issues, including cross group issues? One possibility is 
to use W3C's ETA system. There was a section set up for WAI ER Although we 
haven't used it yet. Those of you who have tried it... please see what you 
think. If you want to try it out you can add yourself as a contact (This 
requires member access to w3c).

Blocks
HB A block is a container for other blocks. At the lower level it is a 
paragraph, a list item, a frame?
WC This is for checkpoint Checkpoint 12.3 - Divide large blocks of 
information into more manageable groups where natural and appropriate
WL "block" a chunk of HTML formed by an element that begins a new line.
WC BM's proposal number was 10.
WL Doesn't understand context.
BM the consensus seems closer to 5 or 7, for lists at least.
/* BM reads from WCAG "For example, in HTML, use OPTGROUP to group OPTION 
elements inside a SELECT; group form controls with FIELDSET and LEGEND; use 
nested lists where appropriate; use headings to structure documents, etc." */
HB Doesn't like the word "block" prefers "grouping." /* reads from thesaurus */
BM Beyond what say in WCAG, "all of these grouping mechanisms should be 
used when appropriate and natural." Also mention tables, etc.
HB So, we're saying a group of 5-10 other things.
BM if you see more than 7 of something, you should trigger the check.
WC If you see more than 7 paragraphs?
BM Break up lines of text into paragraphs. When is a paragraph big enough? 
If 1,000 words, definitely "big."
WL Most of the style rules have to do with ideas being in a paragraph.
WC If more than one idea per paragraph, either manual check or someday an 
automatic check. Need research on the table before can make a decision. 
I've been looking at interface design, someone look at style and grammar?
WL We supposedly ask for proper stylistic choices to be made. There are 
methods for looking for that. We're going beyond that, navigation items, 
that don't appear in prose. However, they use the same sorts of rules.
Action WL Go through Nielsen's site to dig up info on creating groupings. 
esp. usability tests of certain kinds.
Action HB E-mail the group references on style, writing, and grouping.

Event tracking
WL I deal with each issue as it comes up, not keeping track. Therefore not 
one to ask.
HB Move our old log into that system.
WC We aren't expecting that the tool will magically make issue tracking a 
no brainer, we are hoping that it can be used by people like a bug tracking 
system. When someone has an issue they will add it to the system. Len and I 
would then keep track of its progress. We need to resolve issues. Many just 
peeter out. We are currently only tracking issues with AERT, those are kept 
within the AERT as @@'s or listed as open issues. We will have other issues 
raised however and need to keep track of those. Since AERT is not on the 
Recommendation track, I have not been as motivated to thoroughly track the 
issues. Regardless, we do need to track issues and make sure they are 
resolved. ETA has some good features for notifying people, and a format for 
collecting info that could help us organize our issues. It's a database so 
we can make queries. It helps us maintain and archive so we can avoid 
recycling issues.

Notifying authors of caveats
WL What about the "until user agents" clause? Do we have a tool that says, 
"there is a place where you can count on CSS2 being implemented."
WC It's not just when does browser X support something, it's when do users 
begin using that browser. Users don't upgrade for many reasons.
WL do you read EO? From Carlos, "how do we have a tool that let's you know 
what is not supported."
WC TopStyle and HomeSite do a good job of showing you what is or is not 
supported in a variety of browsers and what is included in W3C specs and not.
WL The tool that i envision will warn you if what you've done will not work 
in Netscape4, for example.
WC Where fit in AERT? Checkpoint 6.3 - Ensure that pages are usable when 
scripts, applets, or other programmatic objects are turned off or not 
supported and actually, perhaps need a new checkpoint to cover? 3.2 Create 
documents that validate to published formal grammars. doesn't quite cover 
it, b/c you could validate to a grammar but the support is not there. Need to
Action WC add to AERT a technique that notifies authors when something they 
have done is not supported in a browser, ala the HomeSite/TopStyle method.

Next meeting
Next Tuesday with AU.

$Date: 2000/07/03 16:02:23 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Monday, 3 July 2000 12:05:00 UTC