Hi, I haven't been able to attend the meetings so I don't know if this has been discussed. One aspect to specifying user interfaces is called "user empathy". The idea behind this is to step outside of who you are and into the user's shoes. Were there any user empathy techniques discussed? (Amazing how often programmers dislike that touchy-feely stuff.) Scott
Hi, I'd like to support Kitch's approach to using scenarios to understand user needs. It is an extremely useful tool. Here's a scenario that I quickly mentioned in a previous note, but one common enough that it needs to be addressed. As a blind person is tabbing through fields of a form, how does he know when one form ends and another form begins? Scott
Hi, Chuck I may have missed something, but I didn't see your explanation for not having a separate box for an accessibility style sheet. Could you tell why you believe there shouldn't be a separate place for an accessibility style sheet? Perhaps, you're assuming that disabled users won't want to make some minor adjustments to the accessibility style sheets to fit their own preferences? As I mentioned on the conference call, I've done a fair amount of work with user configuration issues. My goal is in general to give as much user satisfaction as possible. Often I found that users like the flexibility to tweak things to get it how they want it. This makes users feel that the application is adjusting to them rather than they're adjusting to the application. The other important aspect is to let users tweak without learning a lot of additional information or being exposed to the possibility of making unexpected mistakes which they can't figure out how to fix. Forcing them to modify accessibility style sheets will open the possibility of customer support problems either for Microsoft or the provider of the accessibility software when they try to help users find their mistakes. Trust me. I've been down this road a number of times. Customer support people will prefer it this way. Scott PS There's a phrase in the user interface world that user-friendly is programmer-hostile. > You're asking for accessibility-specific UI for a general problem. I do not > want to endorse a separate box for an "accessibility style sheet." > > If we were going to provide pre-defined style sheets for accessibility > considerations, we would populate a folder on the users machine. > > >From there, when you specify a style-sheet, you can "Browse..." and the > style sheet folder appears. Whatever style sheets that are installed are > then listed. > > A screen reader will then have a specific place, on a per-user basis, to put > their own style-sheets in. IE might ship some as part of the default > browser and ship others as a Power Pack, and/or some sort of Accessibility > Pack. > > So the UI would be: > > Check box - "Enable Cascading Style Sheets to format web pages" > Edit box - "File name of users style sheet" > Button - "Browse..." (opens up File Open dialog to users CSS location and > when closed puts the selected file into the edit box) > > -Chuck > > -----Original Message----- > From: Scott Luebking [mailto:phoenixl@netcom.com] > Sent: Tuesday, March 10, 1998 1:21 PM > To: w3c-wai-ui@w3.org > Subject: CSS options > > > Hi, > Here's what my suggestion for the CSS options. > > * Ignore cascading style sheets > > * Use cascading style sheets > > +------------+ > Optional accessibility cascading style sheet | | > +------------+ > > +------------+ > Optional user's personal cascading style sheet | | > +------------+ > > There are two radio buttons for the cascading style style sheets, > The first says ignore style sheets while the second says to use > the style sheets. (The default would be to use the cascading style > sheets.) Under the second button and indented are two file name boxes. > The first file field specifiecs an optional accessibility CSS file name. > The second file field specifies an optional user's personal CSS file. > > Providing for a separate accessibility CSS file in addition to the > user's personal CSS gives the disabled user the option of overriding > various aspects of the accessibility CSS file to more easily > tailor it to his/her needs without needing to duplicate or > modify the accessibility CSS file. > > What do people think of this approach? > > Scott > > > ======= MAIL HEADERS ========================================== > > >From chuckop@MICROSOFT.com Tue Mar 10 19:40:20 1998 > Return-Path: <chuckop@MICROSOFT.com> > Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) > by mail2.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) with ESMTP id TAA27617 > for <phoenixl@netcom.com>; Tue, 10 Mar 1998 19:40:01 -0800 (PST) > Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3) > id <GMZL4CGT>; Tue, 10 Mar 1998 19:36:36 -0800 > Message-ID: <E3A3FFB80F5CD1119CED00805FBECA2F038041FD@red-msg-55.dns.microsoft.com> > From: "Charles (Chuck) Oppermann" <chuckop@MICROSOFT.com> > To: "'Scott Luebking'" <phoenixl@netcom.com> > Subject: RE: CSS options > Date: Tue, 10 Mar 1998 19:36:32 -0800 > X-Mailer: Internet Mail Service (5.5.1960.3) >
The User Interface group will be changing it's name this week to User Agents. The name change is due to the changing nature of what is a browser and the need to deal with new browser technologies. User Agent is a more general label for the working group to deal with the interface between the user and the WWW document. Implications: The mailing list will change from w3c-wai-ui@w3.org to w3c-wai-ua@w3.org. The old e-mail address will work though for an indefinite period of time. WWW address to the home page will change to: http://www.w3c.org/wai/ua Jon Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess
Hi, Here's what my suggestion for the CSS options. * Ignore cascading style sheets * Use cascading style sheets +------------+ Optional accessibility cascading style sheet | | +------------+ +------------+ Optional user's personal cascading style sheet | | +------------+ There are two radio buttons for the cascading style style sheets, The first says ignore style sheets while the second says to use the style sheets. (The default would be to use the cascading style sheets.) Under the second button and indented are two file name boxes. The first file field specifiecs an optional accessibility CSS file name. The second file field specifies an optional user's personal CSS file. Providing for a separate accessibility CSS file in addition to the user's personal CSS gives the disabled user the option of overriding various aspects of the accessibility CSS file to more easily tailor it to his/her needs without needing to duplicate or modify the accessibility CSS file. What do people think of this approach? Scott
here is the URL for the editor, it includes directions and two sample css one for low vision and one for physical disabilities. http://www.tsbvi.edu/technology/csshelp.zip Jim Allan, Statewide Technical Support Specialist Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9453 http://www.tsbvi.edu "We shape our tools and thereafter our tools shape us." McLuhan, 1964
Hello, I have a few thoughts related to previous posts. Those of you who are developers and those of you who have worked with developers in the past can tell me if I am off base. If we were to focus on the needs of users and leave the implementation up to the developer, exactly what type of information should we be providing to the developer. A description of what the user needs to accomplish? A description along with what would be required in order for a user to accomplish a task? It seems like developers would need some guidance on implementation because interaction with assistive technology will play a key role in access. I don't know if we should be providing a list of "desired features", "accessible design principles" , "user needs" or some of everything. As a rough example consider the following. Task: An individual who uses a screen reader must be able to read and fill out an on-line form using only the keyboard for navigation. In order to do this he or she must be able to: 1. Identify the fact that there is a form on the page 2. Get to the beginning of the form (via a landmark?) 3. Read the form control labels (preferably with the option of reading all the labels before filling out the form so he or she can decide if it is worth filling out, and what will be required) 4. enter each form field sequentially, knowing the name of the field or control, and what information is required 5. be able to activate any required controls (e.g. submit, clear) 6. know that form has been submitted successfully Is this the type of information a developer needs? If a developer says, yes, I can provide keyboard navigation for those steps and pages are created according to page author guidelines is that enough? I hope you don't mind me thinking out loud. Kitch
I am sorry, but it is taking me longer than I expected to update the UI WWW pages. I will continue working on pages tonight and have something by tommorrow morning. Jon Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess
Hi, I was wondering how other people feel about Microsoft's deadline for browser issues. I think that there are a number of aspects that need to be discussed and the time framework seems a little too short. Maybe, an approach would be to have Microsoft's browser team extend it a little so that the issues can be cleared up. Another idea would be to invite someone from Microsoft's browser team to participate on the guidelines. In that way, the information flow would be two way and I think a more accessible browserwould result. What do people think? Scott
The W3C WAI Telephone conference call on Browser Guidelines is scheduled for tuesday and friday of this week. By 5:00 CST I will have a revision to the current guidelines. Tuesday, March 10th and Friday, March 13th Eastern Time: 1:00pm to 2:00pm Central Time: 12:00pm-1:00pm Mountain Time: 11:00am-12:00pm Pacific Time: 10:00am-11:00am Dial-in number: 608-250-9281 Participants Code: 874071 (H) Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess
Browser User Interface Accessibility Check List 1=highest, 2=middle, 3=lowest priority, ADD=Item to add, ?=I do not have enough information or understanding to make a recommendation, LQ:=my comments Presentation Adjustability 1 Author CSS disable 1 Author color disable 1 Author font disable 1 Author background disable 1 User CSS override 1 User foreground/background color override 1 User font style and size override LQ: I'm also confused about the intended difference between the "Author disable" and "User override" items. ADD 1 Ability to select from a list of alternate author or user style sheets 1 Display only ALT text for images (complete ALT text) 2 Display TITLES for anchors that are images 1 Display LONGDESC descriptions on user command 1 Display view option for headers only 1 Display view option for headers and anchors only 2 Display view option based on users preferences of selected elements 1 Maintain relative focus positions between views ? Suspend Dynamic HTML events LQ: Is this the same as "Disable client-side scripting"? Orientation Information 1 Document TITLE in title line 3 Document summary information on status line on document load 2 Document summary information on status line on user command LQ: I'm a bit hesitant on the previous two items due to the insistence that "status line" be used. Other mechanisms, such as a floating window in graphical browsers, may be easier given space restrictions. 2 Selected document summary information in menu items (see visibility section) 3 Element identification on status line on focus/mouse over (see next section for psuedo focus) Navigation Commands Link (Anchor) 1 Move to previous link 1 Move to next link 1 Move to link from list 1 Select link Headers 1 Move to previous header 1 Move to next header 1 Move to header from list List Items 1 Move to previous list item 1 Move to next list item 2 Move to list item from list Forms 1 Move to previous control 1 Move to next control 1 Move to control from list 1 Change state of control (control dependent) Tables 3 Move to previous table 3 Move to next table 3 Move to table from list LQ: I don't see why tables deserve more attention than other elements for the previous three items. For example, one could also have "Move to previous definition list" etc. While these may be handy features, I wouldn't consider them to be a priority except with links, headers, list items, form controls, and frames. 1 Move to next column 1 Move to next row 2 Present table row header on status line 2 Present table column header on status line LQ: I like the previous two ideas, but again I'm hesitant about the use of "status line". We don't want to restrict the use of other methods of presenting row and column header information. (Or is this kind of uniformity desired?) 2 Find in table LQ: Find in column, Find in paragraph, Find in list, etc. would also be useful. Frames 1 Move focus to next frame 1 Move focus to previous frame DHTML Events ? Suspend 2 Move to previous element with DHTML event 2 Move to next element with DHTML event 1 Activate event LQ: I'm not sure how DHTML events are different from normal client-side scripting events. Visibility of Accessibility Information 1 Display keyboard equivalents on associated menu items 1 Display navigation commands in menus 2 Description of navigation command and selection options in on-line documentation 2 Description of presentation options in on-line documentation 2 Description of orientation information options in on-line documentation 1 Compatibility with 3rd Party Assistive Technology 1 Use Active Accessibility in Windows 95/NT Code 1 Use SUNSoft Java Accessibility API in Java Code 2 Use of Standard OS Controls/Menus/Dialog boxes -- Liam Quinn Web Design Group Enhanced Designs, Web Site Development http://www.htmlhelp.com/ http://enhanced-designs.com/
Hi, Keyboard navigation uses the concept of focusing on some item and highlighting it like in Lynx, etc. If the item being highlighted is a link or a headline, deciding what text to highlight is usually straightforward. The challenge comes with some of the other structures. For example, if the object is a form, list, or table, what gets highlighted? The first thought would be to highlight the whole structure. The problem with that is how does the user "get into" the structure? What would be the natural flow of navigation? A solution I found useful was to focus on the navigation aspect instead of the structure. Thinking in terms of navigation, the approach that made sense was for the browser to display text indicating the beginnings and the ends of forms, etc. The user then can navigate to the landmark at the beginning of the form. To "enter" the form, the user just moves on from the landmark at the beginning of the form. The beginning and end landmarks for forms, lists, etc had another benefit. Sighted users can usually determine from visual cues where the end was. Blind users had a harder time doing this. A common mistake was to assume that a submit button on a form indicated the end of the form. The blind user might not realize such things as more than one submit button on a form or additional input fields after the submit button. The beginning landmark for forms, lists, etc, could include a little information about the structure. The beginning landmark could tell number of fields in a form or items in a list. This information would help the blind user guage the size of the structure. Information about a table could be especially useful. Numbers of rows, columns, spanned cells, incomplete rows along with border status could help the user guess the purpose of the table. In addition, having the information directly on the page avoided the user having to go though menus. Another navigation problem is how to handle navigating into nested lists and table. Scott
Hi, I have a suggestion which might be helpful for writing the guidelines. It is often useful to write guidelines not so much from the perspective of the writer but from the perspective of the reader. This approach can often make it easier for the reader to understand. Since we want browser companies to understand the guidelines and agree to implement them, we need to think about how the browser company's might look at things. Also, the easier it looks to do, the more likely browser developers will do the needed work. My suspicion is that many of the browsers are written using object-oriented technology. The object-oriented technology has many advantages, but one challenge is that good object-oriented programmers need to think fairly abstractly about the issues, much more abstractly than programmers writing in C, etc. The guidelines reference things like headers, links, forms. One suggestion is to come up with an abstract class name for them. The term 'elements' could be used, but I think a term which somehow conveys the navigation aspect might be very helpful. (Many elements in HTML are not related to navigation.) My suggestion is the term 'landmark elements' or just 'landmarks' for short. (Actually, it might be useful to drop the 'elements' part in case there might be navigation points which don't exactly correspond to HTML elements.) If the abtract class is "landmarks", then various sub-classes can be: links headers paragraphs begin form end form input fields begin list end list list item begin table end table table cell The various types of landmarks actually have similarities in navigation. Explicit navigation e.g. go to link numbered 5 Sequence navigation e.g. go to next/previous header Navigation via list of landarks e.g. go to zip code field in form A few of the landmarks have actions associated with them. The landmark class structure could look like: landmarks headers paragraphs begin form end form begin list end list list item begin table end table table cell action landmarks links input fields The action landmarks could be triggered by explicit specification or by having the landmark highlighted in some way. Does this class structure make sense? Scott
Hi all, It's getting late. I hope this makes sense. I had a hard time ranking some items, because if one feature is implemented it makes others features non-essential. In taking the first stab at ranking the features listed below, I tried to ignore that fact that some browsers may have already implemented these features. While I think these browsers can serve as a model for our discussions I wanted to avoid setting priorities relative to an existing product. However, we may want to survey all the existing browsers and make a list of the best features from each. Generally, I see the top few priorities as: 1. Allowing the user to set colors and fonts, either by passing through OS settings or allowing the user to configure his or her own settings within the browser. 2. Providing full keyboard navigation through all browser features and all web pages. I guess we could say that Lynx and IE already meet this requirement, if pages are authored correctly. However, now we need strategies for better keyboard navigation. 3. Providing status and location information. The browser should display the current focus at all times so that assistive devices can follow the cursor. The user should also be able to exercise appropriate control over the focus. 4. Providing information on where the cursor is in the document relative to the rest of the document and providing information about the document in general. 5. Allowing the user to set preferences for displaying certain information in menus, on the status line or new windows. Browser User Interface Accessibility Check List 1=highest, 2=middle, 3 lowest priority, ADD=Item to add, ?=I do not have enough information or understanding to make a recommendation, KB:=my comments Presentation Adjustability ? Author CSS disable ? Author color disable ? Author font disable ? Author background disable KB: I guess I am confused about author disable too. 1 User CSS override 1 User foreground/background color override 1 User font style and size override 1 Display only ALT text for images (complete ALT text) KB: Should the word OBJECT be substituted for image above? 1 Display TITLES for anchors that are images ? Display LONGDESC descriptions on user command KB: Can the browser generate a list of the page's objects using their alt tags and then have these alt tags linked to their LONGDESC? 1 Display view option based on users preferences of selected elements KB: Based on what I read in the draft browser guidelines, I am envisioning that the browser would generate a list of elements such as the headers, links, tables, objects, etc. The user would then have the ability to choose which elements would be included in this list. ? Maintain relative focus positions between views KB: I am not exactly sure what this means, however maintaining focus when switching between documents and applications should be a high priority. Orientation Information 3 Document TITLE in title line 1 KB: Providing document summary information is a high priority and the display of this information should also be based user preferences. I would suggest that when the document loads, the status line includes document information similar the example in the browser guidelines. For example, "Document is 2635 bytes long with 22 headers, 14 links, 1 table and 5 form controls". Then, once the focus move to an element the status line is updated with information about that element relative to the rest of the document. For example, "Header 2 of 6, 40%" where 40% represents the cur sor position relative to the whole document. This is just a guess, I haven't really thought it out. Finally, it would be nice if additional page information can be accessed through a user command. For example, Netscape 4.04 has a page info command that provides a document summary including document size. Navigation Commands 1 Move to previous element, next element, and from a list of elements (created by the browser) to a specific element in that list for : LINK, HEADER, LIST ITEM , FORM CONTROLS, TABLE, FRAMES KB: I am still not sure I am using the word list correctly. Are we talking about a list of elements the browser would create or an item in a bulleted list? In addition to the above: Link 1 Move to a link from command line (from previous post) Tables 1 Move to next column 1 Move to next row KB: The user needs to be able to use keystrokes to move browser's focus through a table's rows and columns while accessing row and column names from the status line. As above, it would be nice if the user could choose which items he or she would like displayed on the status line. ? Find in table KB: Does "find in table" mean the user should have the ability to search for a text string within a table? Forms 1 Move focus to beginning of form (added from previous post) ? Change state of control (control dependent) KB: I am not sure what this means? DHTML Events 3 Suspend 2 Move to previous element with DTHML event 2 Move to next element with DTHML event 2 Activate event Visibility of Accessibility Information 1 Display keyboard equivalents on associated menu items 1 Display navigation commands in menus 1 Description of navigation command and selection options in on-line documentation 1 Description of presentation options in on-line documentation 1 Description of orientation information options in on-line documentation Compatibility with 3rd Party Assistive Technology ? Use Active Accessibility in Windows 95/NT Code 1 Use SUNSoft Java Accessibility API in Java Code ? Use of Standard OS Controls/Menus/Dialog boxes
Browser User Interface Accessibility Check List 1=highest, 2=middle, 3 lowest priority, ADD=Item to add, ?=I do not have enough information or understanding to make a recommendation, JA:=my comments Presentation Adjustability JA: I am not sure of the distinction between disable and Override. For example, in IE or Navigator when a user says use "my colors" is that overriding the authors colors or disabling the authors colors. Or does Override include disable? ? Author CSS disable ? Author color disable ? Author font disable ? Author background disable 1 User CCS override 1 User foreground/background color override 1 User font style and size override 1 Display only ALT text for images (complete ALT text) 1 Display TITLES for anchors that are images ADD Display ALT text and Titles for anchors that are images ADD Display text within OBJECT tag 1 Display LONGDESC discriptions on user command 3 Display view option for headers only 3 Display view option for headers and anchors only 1 Display view option based on users preferences of selected elements 1 Maintain relative focus positions between views ? Suspend Dynamic HTML events Orientation Information 1 Document TITLE in title line 2 Document summary information on status line on document load 1 Document summary information on status line on user command 1 Selected document summary information in menu items (see visibility section) JA: this should also be included in Navigation section 2 Element identification on status line on focus/mouse over (see next section for psuedo focus) Navigation Commands Text highlight, an insert cursor or other indicator usable by assistive technology is needed as a psuedo focus for 3rd party assistive technology for navigation of HTML elements. The psuedo focus is needed for most of the following navigation commnands to benefit users with disabilities. The following is an initial list of navigation commands. The commands should be available from the keyboard, menus and possibly in a user defined set of toolbar commands. List of Important Navigation Commands Link (Anchor) 1 Move to previous link 1 Move to next link 1 Move to link from list ADD Move to link from menu ADD Move to link from command line (see Scott L. message about Lynx and links) 1 Select link Headers 1 Move to previous header 1 Move to next header 1 Move to header from list ADD Move to header from menu List Items 1 Move to previous list item 1 Move to next list item ? Move to list item from list JA: what is the purpose of this Forms ADD Move to beginning of Form JA: this would be very useful for search engines 1 Move to previous control 1 Move to next control 2 Move to control from list 1 Change state of control (control dependent) Tables 2 Move to previous table 2 Move to next table 2 Move to table from list 1 Move to next column 1 Move to next row Present table row header on status line Present table column header on status line ADD Present table row and column header for individual cell on status line 1 Find in table Frames 1 Move focus to next frame 1 Move focus to previous frame ADD Move focus to frame from a list DHTML Events ? Suspend ? Move to previous element with DTHML event ? Move to next element with DTHML event ? Activate event Visibility of Accessibility Information 1 Display keyboard equivalents on associated menu items 1 Display navigation commands in menus (For example have a main menu item labled nn Headers, where nn is the number of headers in the current document. The sub menu items would include Next Header, Previous Header, List of All Headers, and a Dynamic List of the first 10 headers.) 1 Discription of navigation command and selection options in on-line documentation 1 Discription of presentation options in on-line documentation 1 Discription of orientation information options in on-line documentation ? Compatibility with 3rd Party Assistive Technology JA: I am not sure how this would work. There are many 3rd party assitive tech addon. Would each browser be required to test with all tools available? Or, should browser manufactures publish or codevelop or use some other mechanism to ensure that 3rd party developers have a standard way to access the information. ? Use Active Accessibility in Windows 95/NT Code ? Use SUNSoft Java Accessibility API in Java Code 1 Use of Standard OS Controls/Menus/Dialog boxes Jim Allan, Statewide Technical Support Specialist Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9453 http://www.tsbvi.edu "We shape our tools and thereafter our tools shape us." McLuhan, 1964
Hi, Sometimes, when designing a user interface, it is a good idea to look at what people currently use and why they like it. A number of blind people have told me that they like how Lynx will let them select links by number. I thought I would analyze this a bit. There are several advantages to selecting links by number for blind users. A major benefit is that the blind user does not need to navigate to a link to select it. For example, suppose that the blind user is reading a page list with 22 links, but isn't sure which he/she wants. The blind user reads through the 22 links and then finds that it is the eleventh link that is needed. With Lynx, the user just types in 11. In a graphical browser, the blind user has to navigate back up to the eleventh link. Since screen readers are not as efficient for navigating graphical displays as reading text, navigating back to a link requires much more effort by the blind user. Lynx annotates the web page by adding a indicator with an id number for each link. This web page annotation has several advantages for blind users. The first is that links are a little more clearly identified for blind users in Lynx than in graphical browsers. In graphical browser, the blind user has to find a link by looking for color changes in text fonts. The blind user can run into several challenges with this. One problem is that the text color for links can change from web page to web page. A second problem is that text links in a line can appear as just one long link. The third problem is that the blind user has to change operating modes from just reading text to looking for text color changes which can be awkward, With Lynx's annotating web page approach, the blind user only has to read text. So, Lynx's handling of links has two key aspects; 1. each link is marked with an id 2. a link can be selected by id in addition to location Assigning an id to each link can have some additional benefits. For example, if you want to know the URL of a particular link, you can type a command like : url 23 and the browser can tell you the url for link 23 without having to navigate to the link. (The 'url' command could probably be abbreviated to 'u'.) Another way to look at link ids is as ids for 'landmarks' on a web page. Suppose you're at the bottom of the web page and you wanted to scroll back to the neigborhood of link 12. You could type: link 12 and the browser could scroll back to that link. Scott
Hi, One idea to include in the guidelines is to have the option to enter commands to the browser via the URL field. This command option can have many, many uses. A significant one would be choosing a link by number. The command option would be on some user configuration panel and its default setting would be off. When the command option is active, the browser can easily identify whether the user is entering a command or a URL. Basically, the criteria would be on the first non-white-space, non-null, complete substring as follows: a. if the entire substring is only a period or a single slash, then it can be a command b. if the substring starts with a digit, contains only digits and punctuation, e.g. 3.5,6, and is not in IP address format, then it can be a command c. if the substring does not start with a digit and does not contain a period nor a slash, then it can be a command (I have a small nagging question that the third set of criteria might need to be a little tighter in case the browser is used on an intranet where just a machine name is specified as the initial URL, e.g. 'homedocs'.) A special key combination, e.g. ALT-SHIFT-U, would move the GUI focus to the URL field where the user could type a URL or a command. (Note, this key would have universal access benefit since sighted people would find it helpful while it helps reduce the navigation a blind person has to do to get to the URL field.) What kinds of commands could users specify? Hold that thought for a bit. Scott
It there a typo in the guideline draft; Should the first "next" be "previous?" > Frames > > Move focus to next frame > Move focus to next frame What ordering do you assume on frames in the frame set. When it is all visible, you might argue it doesn't make any difference. But an ordering might be induced by frames visited. Jim Thatcher IBM Special Needs http://www.ibm.com/sns 512-838-0432 thatch@us.ibm.com
Other items discussed during the telephone meeting 1. Need to increase participation of browser developers 2. Need to increase particpation of third party assistive technology developers 3. Need to have browser accessibility features to reduce the requirement of WWW authors to write perfect accessible WWW pages 3. Assisting in building relationships between browser developers and third party assistive developers 4. The definition of Type I Browsers witch provide direct accessibility anf type II borwsers that provide indirect accessibility through assistive technology. Commercial browsers have some of both characteristics 5. Brief overview of current checklist Meeting note will be published when available. Jon Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess
This is the final agenda for our telephone meeting today. I moved the discussion of our purpose to the beginning, since some people may need to leave early and is probably our number one issue before we start working on the actual guidelines. Final Agenda 1. Introductions 2. Discussion of Mission of User Interface Guidelines A. Specialized browsers B. Major browsers and assistive technology 3. Brief Review of Draft Guidelines and Checklist A. Missing items B. Item clarification C. Controversal items 4. Action Plan A. Major issues that need to be discussed first B. Goals for the C-SUN meeting Telephone meeting information. Wednesday, March 4th at 12noon to 1:30pm EST Caller paid dial-in number: 608-250-8227 Participant code: 713230 The following people have signed up. James Allen Chris Wilson Scott Luebking Tom Wlodkowski Geoff Freed Gregg Vanderheiden David Poehlman Kitch Barnicle Jon Gunderson M. T. Hakkinen Evan Wies Ben Weiss Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess
Hello, My name is Evan Wies. I am a Research Engineer at Immersion Corporation. Immersion develops force-feedback technologies -- technologies that let you "feel" things on your computer. Although our products are targeted at the mass market, we are very interested in making them a useful, if not invaluable, interface for people with disabilities. We have spent a great deal of effort on integrating force-feedback with the Web. By being in this working group, I hope to share our ideas with you, as well as to learn ways to improve upon our work. Our web page is at http://www.force-feedback.com. Feel free to email me at evan@immerse.com if you have any questions. Sincerely, Evan Wies Research Engineer Immersion Corporation evan@immerse.com
On a recent telecon I took an action to provide a lead for the Linux screen reader I have heard about. The program is at http://leb.net/pub/blinux/screader/screader-1.3.bin.tar.gz and a good starting point is http://leb.net/blinux/ Al Gilman
Chuck, The Amya development team asked for input from the WAI project on accessibility. The conference call was setup for input to Amaya group from the WAI prgram office. Amaya is developing their goals for the next few months and they want to do somethings with acessibility. Your main concern is probably the discussion of the browser guidelines themselves, this is not part of the discussion with Amya group. The guidelines will be discussed within the browser group, hopefully within the next few weeks. But comments and discussion are welcome anytime. Jon Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services University of Illinois at Urbana/Champaign 1207 S. Oak Street Champaign, IL 61820 Voice: 217-244-5870 Fax: 217-333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund http://www.als.uiuc.edu/InfoTechAccess
Hi! I am the CEO of Opera Software. We make the Web browser Opera. I have a special interest in making the Internet acessable. I believe that the Internet is a tremendous oportunity to make things better. It started off great with the original standards and now we just need to continue making progress. We try our best to make the Opera browser as accessable as possible and users in the beta group include two guys that use headwands on their head to access the computer and some user with no or limited vision. They give us great feedback on how to improve our product. I hope that being part of this group will give us even more great ideas and hopefully we can contribute with a few as well. -- Regards/Ciao/Kær kvedja/Vennlig hilsen/... Jon S. von Tetzchner Opera Software Jons@operasoftware.com http://www.operasoftware.com Opera - The browser that is made for you.
Hi everyone, As much as I hate talking about myself, I honored Jon's request and added a few paragraphs about my background to a web page at www.interport.net/~kitch/kitch.html . The short version is that I work part time at the American Foundation for the Blind, my undergraduate degree is in biomedical engineering, and I am currently doctoral student in Health and Behavior Studies at Columbia University. I am interested in human-computer interaction and I will be conducting a usability study of GUI interface elements from the perspective of speech users. I hope that I can offer a contribution to this group as it addresses the user interface needs of individuals with visual impairments. My colleagues at AFB will also be playing a significant role in supporting my participation in this group. On a side note, I thought that if I were going to refer people to my web page I should make an effort to update the page using the latest page authoring guidelines. I thought that I could review guidelines, use the guidelines, and begin to get myself up to speed in preparation for participating in this working group. Needless to say, it quickly turned into an ordeal even though my page is basically a text-only list of links to conferences and articles. So I quickly realized that I have a lot to learn and things aren't as always simple as they seem. I look forward to working with all of you. Kitch