WAI Face2Face Meetings, Los Angeles Marriott March 22, 1998 Agenda 1. Morning Session: A) Page Authoring Guidelines, Chuck Letourneau and Gregg Vanderheiden Legend (Abbreviations Used to Identify Speakers/Participants) Al G: Al Gilman Chuck L [also CL]: Chuck Letourneau (Starling Access) Chuck O: Chuck Oppermann (Microsoft) CK: Cynthia King (Gallaudet University) D Clark: David Clark (CAST) Daniel D [also DD]: Daniel Dardailler (W3C) Dennis D: Dennis DeVendra (Recording for the Blind & Dyslexic) GJR: Gregory J. Rosmaita (American Foundation for the Blind/AFB) GK: George Kerscher (DAISY/Recording for the Blind & Dyslexic) GV: Gregg Vanderheiden (Trace) HB [or Harvey]: Harvey Bingham (Yuri Rubinsky Insight Foundation/YRIF) Jaap: Jaap van Lelieveld (European Blind Union/EBU) Judy: Judy Brewer (WAI Chair; W3C/IPO) Kevin: Kevin Carey (RNIB) Kitch: Kitch Barnicle (AFB) Len: Len Kasday (AT&T) Madeline: Madeline Rothberg (WGBH/NCAM) Mark H: Mark Hakkinen (Productivity Works) Max: Masafumi Nakane (W3C/Keio University) Phil J [and PJ]: Phil Jenkins (IBM SNS) Peter B: Peter Boscher (British Computer Association of the Blind/BCAB) SM: Sarah Morley (University of Hertfordshire) Steve: Steve Tyler (RNIB) Tom: Tom Wlodkowski (CPB/WGBH/National Center for Accessible Media) WC: Wendy Chisholm (Trace) Will L: Bill Loughborough (Smith-Kettlewell Institute) Morning Session Page Authoring Guidelines -- Chuck L. and Greg V. 1. object: brainstorming session, not a conclusion-oriented meeting Daniel D: why not try to attain consensus? if we can, we should GV: not all members here, only economically advantaged, don't want those not here to feel that they are being left out of the loop; will reach consensus through the lists 2. first topic: issues or topics that they haven't yet seen addressed on the list Phil Jenkins: browser detection by site servers DD: user agent detection/negotiation; not a usability issue, but a performance issue; W3C does not encourage it Al G: present practice of browser sniffing not using HTTP negotiation, reading user Agent and making decision; this is more a site management issue than an accessibility issue GJR: it is an accessibility issue when a user is shunted to a NOFRAMES section that simply says "Join the 20th century and download a frames-capable browser" or a dead- end page; misuse of both browser detection and NOFRAMES could lead to the shunting of those who-for whatever reason, physical, financial, or philosophical either choose to, or have no choice but to, access the web via a text-based browser--into a cyber-ghetto; text-only pages tend to be less conscientiously updated than their graphically-oriented counterparts-we should be striving to promote universal access-access built from the bottom up, rather than trickle down access Al G: there has been discussion of this in PF of user control over browser sniffing; will follow up with GJR on GL list under title: "Re: Browser Sniffing" GV: is the problem Legacy Browsers? not even latest browsers support CSS as defined by W3C; concerned that we shouldn't have something in GL that author needs to do to accommodate new free upgrade; users have told me that their sys admin won't allow them to upgrade their version of Netscape, and there are others who can't run the latest version of a browser on their older systems GJR: a much larger problem is posed by server based browsers--user has no control over maintenance/updating; what about the majority of users that have very old equipment and no control over user environment; those whose PCs are turned into dumb terminals when they log onto a shell account; it is far easier to obtain a GUI browser for an older system (Win 3.x/Mac) than it is for an average user to compile a server-side browser; number of people using ancient versions of Lynx with severe limitations and only HTML 2.0 capacity is extremely large; sys admins just don't bother, nor do they care to upgrade GV: can't people telnet to a site that has a more current version of Lynx? GJR: problems with that scenario is that the number of sites that offer public Lynx access via telnet is shrinking; moreover, most have limitations: some disallow the Go-To command, so that one can only follow links, some disallow setting links to be reported as numbers; can't use a disability/accessibility-tailored configuration file, can't save bookmarks; not a very practical solution; the Blynx project has tried to increase the visibility of publicly accessible Lynxes and provide users with ammunition with which to get their sys admins to upgrade the versions of Lynx on their servers, but many sys admins aren't interested in upgrading despite Scott McGee's Patch- O-Matic (http://sol.slcc.edu/cgi-bin/lynx/patch-o- matic.cgi); there are also offline versions of Lynx: Lynx32, MacLynx, Lynx386, Blynx386, etc., but their maintenance needs to be more fully integrated into the maintenance of Unix Lynx; perhaps W3C/WAI could work with porters to increase visibility of options to users, Will L: use Lynx in a similar manner to Amaya; every form of software has accessibility issues, but unless we focus on content rather than presentation, we are missing a big opportunity GV: INTERIM tag in GL meant to do that; asked WL to go through guidelines and send him comments Will L: we need to promulgate some sort of proactive stance: "if you don't tag, then you're not in our bag"; if put teeth into guidelines/WAI requirements, problems will go away; web itself must have an accessibility profile; many things can be or will be handled by proxy servers, user agents; need to concentrate on the meat of the web-- content, not presentation GJR: www.sony.com illustrates problem with general recommendations; what we need is specificity, backed by an HTML validator and a semantic/logical accessibility parser; both need to be auto-validators/parsers; WAI could recruit volunteers to periodically spot check those sites bearing our logo/logos Dave C: problem defining the word accessibility as it relates to the web; i too have trouble defining it; is it browser-dependent? causes undue hardship for web developer; wonder if we should strive for a LCD standard Chuck O: basic standard, not definitive definition of accessibility; for example, content providers don't want ALT text displayed while images being loaded; would like to propose a CSS addition that will allow ALT to be displayed or not displayed Kevin: isn't just a web issue, it is an everything issue CK: site authoring tools; many developers using site authoring, rather than page authoring tools; need to address this--should it be in the GL group or in the UI group? GV: forward on to Jutta and authoring tools group; fact that tools used covered in guidelines, but needs to be expanded and further defined Chuck O: how relevant are HTML guidelines when most sites are being developed using third party tools? GV: GLs used by tool makers and browser manufacturers Judy: can automate accessibility to a certain extent, but there are things that you can't automate and for which you need guidance; for now we need comprehensive GLs for page authors as well as tool and user agent manufacturers Jaap: support what Chuck said; change GL intros to state that we are aware of the problem and remove onus from author alone; Phil J: propose that make guidelines specific to HTML version 4; put legacy issues into separate document Judy: under that model, the guidelines will fragment endlessly GJR: hard enough getting them to read one document; why split? DD: no need: HTML 2 and 3.2 are merely subsets of HTML 4 PJ: HTML 2 and HTML 4 worlds extremely different GV: it is the user who is confronted with that situation, not author unless user in an intranet Len: intranet concerns: can have situation where you make sure that all persons with disabilities have the latest stuff, would like one simple document that addresses the latest, specifically tailored to intranet administrators Judy: if there are specific things that need to be mentioned for HTML 2 or 3.2 specifically because they have been superceded; perhaps should be addressed in an addendum GV: Len, please go through guidelines and point out concerns/issues, means of consolidation and streamlining; don't want GLs to bog down and become too complicated Chuck O: people don't code to HTML specs, but to browser capabilities CK: isn't the use of interim providing back level support? can't it state that supports browser X? Jaap: NEW should be CURRENT; refer to different browsers and PRs GV: problem, some of the new aren't current because aren't in browsers HB: tried to download GLs and the URLs had HTMl in them which corrupts DOS filenames; GJR: points out the problem with interim; here we are, in GV's term, the economically advantaged, and HB is using a DOS only laptop PJ: there is shareware that will convert links to 8x3 convention; site snagger GV: Wendy Chisholm has page called "Kaboodle" (sp?) with list of browsers and shareware; please send to her and she will add links and descriptions AG: do you want that thread in Tools/RC? Len: RC page will point to Wendy's page Will L: page authors writing to browsers misses the point; what is on the web is an HTML document; because there are so many user agents that decode all of the browser specific tags, still have to focus on the one issue: what is being put in the document GV: most critical part of GL is that info exists in page, good point Bill Phil J: agree: keep one doc; want to be as usable as possible; if we assume a person has a screen reader and a HTML 3.2 browser and some sort of support for CSS then should tailor GLs to that; what are we assuming? what are the GLs written to? GV: there are no accessible pages and never will be only levels of accessibility; accessibility means usable by persons with disabilities; point of GL is to make them usable by PWDs; required: that which is necessary for persons to perceive info; recommended, that which makes pages easier to perceive/interpret: usable is the key word Al: as i read GL, i get a different picture; 1) it isn't productive to talk in terms of spec revisions; 2 thresholds: any browser threshold and a strictly up-to- date; 2) have to understand what is being marked interim and new; new is the problem because client installations don't support them Len: specific set of assumptions for basic browser capabilities; baseline set becomes definition of NEW WC: not everything has a label; several things have neither a NEW or INTERIM Len: what does NEW mean? that it is in the PR? WC: in PR but not supported by a critical mass of UAs Jaap: 1) forms: why not add guidelines on how to write a form to lay out principles of what a form should contain to be useful; 2) scripting: talk a lot about text-based browsers, but none support scripting; can we ask for alternate input for forms that are guided by scripts? 3) ask UI for fully text-based browsers that support scripting and secure sockets GJR, Bill, and Jaap volunteered to draft a form recommendation for GL DD: misuse of dynamic capabilities of technology; performance issues may drive this; tricky issue GV: guidelines don't want to bog down with form recommendations; look for examples and put in collection on W3C site Judy: perhaps scope of EO WG; samples needed; point over to EO collection GJR: are we saying that INTERIM will be replaced by RECOMMENDED; define critical mass of UAs-to my ears it smacks of browser-specificity; what is the "future" of INTERIM? GV: INTERIM means that someday this will disappear; here because has to be here; critical mass comes from listening to disability groups DD: as long as the things that the guidelines ask me to use CSS for presentation as a recommendation becomes an issue as an author whether recommendation out-trumps aesthetics/design; can live with bad design; template for W3C pages not GL compliant; looking to change it using CSS properties, even though will not look good on browsers that don't correctly implement CSS; publicity marketing issue GV: put on agenda whether we should put things back in GLs that we've taken out; industry not in a position to be forward-looking in expectation that some day their pages will look nice; have we deprecated some things too early in GLs DD: as long as recommended OK; it is the required that i want W3C to be compliant with required GV: 1) would like WAI resources to include funding for Lynx; commission projects on volunteer basis? 2) is there a Lynx registry? GJR will lead group to investigate what WAI can do to: 1) analyze technical level of Lynx; 2) investigate capacities of latest version, its accessibility features, and plans for advancement; 3) increase availability of Lynx on public telnet sites; worldwide network of latest updated lynx; perhaps on servers sitting outside corporate firewall; 4) foster ISP adoption of latest version; 5) explore validity of Lynx-Me or Lynx-It application of Lynx: 5) proxy helper server that does things to page to make it more accessible; table-cracking, etc.; 7) facilitate closer coordination of workstation-based ports of Lynx with mainstream (UNIX) Lynx development Chuck O: not realistic to go out to other sites to use Lynx; don't blame updating on ISPs; they're just out make a quick buck; don't know how to update Lynx or have security/stability concerns; more an issue for EO than UA-let EO show ISPs how to provide Lynx Will: use Lynx as a test-bed a la Amaya Al G: use Lynx as a testing platform; build in new things to Lynx GJR: get W3C-sponsored volunteers to participate in Lynx- Dev Al G: always going to be people on the tail; ideas: 1) is possible to draw a line; trying to fix web service to convey info is not most effective means; there is a cross- over point; most reasonable thing is not to push web to solve everything; 2) demographic information: should we be researching user population: how many where they are geographically, what the capacities are; can't make the present release of GL contingent on this, but is anyone working on this? perhaps UA group? 3) should Len's group be the arbiter of make-or-break situations? GV: one of the beauties of lynx, particularly user based Lynx is that there isn't much below it; power of Lynx is that as long as it works with what we are doing it is impossible to be locked out Al G: hardware requirements low for server side lynx; need only VT100 emulation and you have access to a host running Lynx; brings tech threshold GJR: tie ports to development of Unix-based lynx; coordinate and support so that development of ports tied to development of Unix-lynx Guido: INTERIM category vast, includes things with marginal historical validity; category called OBSOLETE, slowly move into OBSOLETE, stay there for one or 2 releases then drop off; propose that OBSOLETE be added to terminology GV: can look into it; add to Will L's task list for analysis of the INTERIM items Len: telnet and proxy support a criteria Jim A: continue lynx discussion this afternoon in UA session; been only looking at GUI browsers; need to look at Lynx, phone access, alternate means of access 3. TOPIC: Demographics Chuck L: ID-ing user profiles/demographics tricky; constantly changing Kevin: demographics important but expensive to do accurately, if W3C has the money, then we should do it Judy: want to pirate other people's demographics; wouldn't be doing our own, but using others' Kitch: Georgia Tech graphical digitalization center does demographics; self-selected; 20,000 users; report methodology, do ask a few disability related questions, should ask them to add a few more; sample of visitors to web site, widely promoted but self-supported Jaap: CIA World Factbook as source Harvey: user profiles of how set up machines for accessibility GV: move topic to EO and/or IG 4. TOPIC: Browser Detection AL: sniffing user agent DD: defeats caching mechanisms in the web GV: is there anything we can or should be doing to prevent shunting off to browser-specific/tailored pages Al:: should focus on 1) browser sniffing: architecture issue that goes beyond guidelines; define as offline homework GV: server guidelines document? don't have anyone handling servers? should it go to Tools? Judy: yes Jim: user agent is actually the server; interacts with user agent; UA will address/field suggestions on this issue Judy: done Chuck O: change user agent string to prevent scripting 5. TOPIC: ALT text pointed questions/major issues (GV) 1. what is the role of ALT text? 2. confusion that results from role when graphic is a link and when it is not a link 3. confusing to tell that ALT should be function not description 4. school of thought that all graphics which are purely decorative be classified as so and disappear; others want all described 5. use of TITLE to pass additional descriptive language or other additional information; LONGDESC for descriptive text; problem with LONGDESC is that it isn't supported on all elements that might need to be described 6. problem: explain to authors what it is they need to do once a decision is reached 7. backwards compatibility: if define it differently than in the past must ensure that legacy pages work 8. HTML 4 says should be supported, but not how it should be used? 9. machines automatically generating ALT text: can generate something, which is better than nothing, but less than what can be generated by human suggestions 1. generation of new tag: AUTOALT -- if machine generated ALT text would be inserted as AUTOALT, in absence of ALT browser would use AUTOALT; names: AUTOALT, AUTO, AUTODESC 2. decorative graphics marked by a distinguishing character, such as a tilde, followed by description, if turned off decorative graphics would not be shown; user control of 3. (JAAP) complicating factor: ALT text used as tool-tip; (GV) browser issue; (JAAP) must be rules for use since being converted to tool-tips; (GV) will ask Chuck O to explain implementation in IE4 4. (Peter B) will not get consensus about what should be done; waste of time looking for it; impossible to develop criteria for what is decorative and which is content; must have over-arching criteria where access to content is primary; forget about trying to get detailed rules; 5. (Madeline) reiterated GV's suggestion machine generated one would say "Chart: put your description here"; 6. (GV) graphics used purely to position things would have discrete tags 7. (Al) to wrestle with this topic, have to have what goes in page (human decision), what authoring tool does, what browser does with it; going to take time, but that is best path 8. (Kevin) interpretation of author's intentions not a problem for intermediary; intermediary should not be putting right what author has done wrong; leave decorative discussion off 7. (George) because of the ALT was not required before 4.0, a lot of info was missed; now object is to convey info; if author feels decorative, don't care if i get info about it; complicating factor is that in past it was not required in the future it is 8. (Len) problem facing is that trying to put things in binary decisions; any given image has multiple aspects; make suggestion: (extreme form) get rid of LONGDESC and use ALT text in a series in decreasing order of importance, user agent needs a way to traverse hierarchy; send mail, mailbox with door open; mailbox with door open and concrete in ground; (less extreme) take most important in ALT put other in LONGDESC 9. (Wendy) features: style sheets and XML will help; what to work into HTML and what with XML 10. (Bill L) no such thing as decorative to an author; will very rarely acknowledge that decorative elements are not essential; trying to get authors to classify according to Len's schema going to be so difficult as to prove impractical; AUTOALT vaporware; don't have to deal with it; not presently a way to do it in a way that anyone can use; end users divided by irresolvable conflicts; idea that something is just aesthetic and doesn't have content needs to be discussed; (GV) actually putting things in tools; have asked us for advice 11. (Steve) 1) need to give some kind of concrete feedback to companies that don'[t know what to do; 2) support Len's suggestion as one of the most concrete; 3) conflict comes from use of info: for what purpose are you using the info on the page? 12. (Phil) do we accept the notion that we are using the source file as a source of information; trying to get info from the author's head to the user; (GV) browser may be able to determine some things from semantic context; (DD) if you consider the filename case and stick in alt it is a page authoring issue as well as a user agent issue 13. (GJR) have user agent get info from referenced materials, especially with imagemaps; if no semantic info available, have browser get the title of the page and return it instead of the URL (provided, of course, we can get UAs to provide us with USEMAP substitutes); link of images contained in documents, which would provide means of linking/quickly accessing LONGDESCs; have browser detect identical URLs and substitute hyperlink text for ALT/TITLE- less graphical links 14. (Dave C) slippery issue; crossing the barrier from form into function; goes to the heart of what is the content of the page; need to explain the rationale explain why it is needed; leave creativity of how to implement to the author 15. (Guido) won't be able to infer correctly whether a graphic is decorative or semantic from source; perhaps we add a tag to the OBJECT such as type: LOGO, DESCRIPTIVE, WALLPAPER, using CSS user can control which will be displayed; author can then use any type of description that he or she wants; would be a class attribute for IMG; (several members expressed confusion); (GJR) point of clarity: Len's suggestion is layered in, Guido's is author defined conveyance of intent 16. (Tom) placing a lot of faith in authors; function versus image; have no problem using the alt tag as a function, have the function be a link; need to be careful with language 17. (Chuck O) bad idea to add more attributes; (DD) what about class?; (CO) excellent attribute, but more work 13. CO: Microsoft put tooltip on images to raise visibility of ALT text to authors; yes it got abused, but some info is better than none; (GV) what is the precedence? (CO) display title in all cases, if title not present, use alt, if no alt use nothing 14. (Harvey) we need to enunciate precedence of pieces--have all users agents use the same ordering; GLs must enunciate this; 15. (Steve) concentrate on class; amalgamate Guido and Len's points; need to think about other forms of access that don't involve screen--this is where authors will be encouraged to use alt et. al. because output devices (i.e. phone) don't have screens GV's Summary 1. everything important to authors; Will L's point echoed by CO-authors consider everything on their pages to be content; need to frame GLs so as to clearly delineate between structure/content and presentation 2. err on side of including info and mark it so that it can be excluded by those who don't want it via their UA 3. make sure that empty alt and any obviously stereotypical strings are illegal 4. summary of discussion based on collated notes will be posted to the IG lists 5. the topic "what to do until the browsers catch up with the current PRs" will be addressed on list Afternoon Session Presentation: Sarah Morley (University of Hertfordshire) study has 2 aims: 1. to ascertain whether web pages authors are able to use WAI guidelines effectively to produce accessible pages 2. to ascertain whether pages they create are accessible to the blind 2 groups of students will create pages: 1. those who have experience creating web pages and those who have never used/studied HTML or CSS 2. blind users who will test pages will range from novices to "power users" how the study will work 1. students will design pages under observation 2. student output will be made available on the web to be remotely evaluated by blind users; some will be invited into the lab for observation of navigation 3. tasks: visit web site, then fill out form/questionnaire Questions for SM Jaap: which browsers will be used SM: range of browsers and range of screen readers GJR: screen readers only? SM: screen readers and/or braille displays Len: how are participants chosen? SM: recruited from RNIB members, BCAB, etc. George K: content that will be developed will be a variable as well--some kinds of content are easier to be made accessible than others; need a large range of content to test SM: excellent idea; will also use chuck l's styling pages Bill L: are any of the web authors and designers blind? SM: no--or, rather, not yet