Jonathan, On Monday 19 December 2005 18:07, Jonathan Chetwynd wrote: > Ronan, > > as an accessibility consultant I use a variety of equipment and > operating systems, linux since '97-'98**, OS X currently and windows > whenever, certainly all three every workday.
Yes, the inclusion of legacy systems into new systems... that painful old problem. Luckily, pre-2000 PCs are totally underweight for the simplest SVG applications, so we are technologically constrained to winXP, win2K, winME, and the serious OSs. > > Accessibility has to be included at each level, from document through > to application and operating system. Agreed. And I would add that there is a need for consistency. specifying the source of input is inappropriate in the document, and specifying the mouseover effects is inappropriate in the OS. I think we would be most prudent to all agree to a set of standards, and them implement those. The thing that would make me happiest is using metadata tags (hence outside of SVG namespace) to describe some behaviour that you can either pick up through a standardized set of scripts or through built-in UA functionality. > It is possible and indeed likely that there may be conflicts, and > this is only one reason why it is critical that accessibility is > included at each level. > Indeed KDE, Gnome and Mozilla each have helpful accessibility experts. > > It is important to separate out DOM level keyboard events such as > text entry from the general application functionality to which 1.1 > refers. > > At the document level it may for instance be essential to provide > some visual indicator to the keyboard user to help them identify > where they are. > in HTML this is frequently a border around the graphic or a change of > background colour. > This can be done by the application, but is frequently controlled by > the author. > These de facto standards have arisen for HTML but are remarkably > absent from SVG at the present time: > These may be defacto standards in html, but SVG applications are far closer to QT or GTK applications than they are to html apps. I propose to you that it makes good business sense to provide shortcut functionality along the lines of those frameworks, and that app developers will be *forced* to do this by their managers when SVG applications begin to fulfil commercial requirements. I firmly believe that it is far more in the interests of the parties interested in accessibility to get the user agents and viewers to implement accessibility hooks that can be implemented by developers than to ask each developer to figure out how to do it themeselves in the code. This is simply asking for trouble. I personally would be happier with a standard we can all live with that offers a lightweight solution via scripting, using declarative tags. Like what the widgets people have been doing for years now with declarative widgets. > See WCAG 2.4: Provide mechanisms to help users find content, orient > themselves within it, and navigate through it. > and 2.4.8 in particular: "Using an icon or text to indicate current > location within navigation bars." > http://www.w3.org/TR/WCAG20/guidelines.html#navigation-mechanisms > > Arbitrary links are likely to be confusing for most users, what is > needed are standards derived through experience. > There is to date remarkably little keyboard navigation data available > for SVG which makes it harder to create techniques and guidelines. > True. Even more perplexing is the addition of new dynamicallay generated links. SVG applications can add/remove links that the developers may not have known about (think wikis). Tabbing is a fine way to go, but is rather fragile when used in context of the complexity that SVG can throw at you. Ronan > Chris Lilley: "an SVG techniques document would help" > http://lists.w3.org/Archives/Public/www-svg/2005Dec/0044.html > > Do please try our keyboard navigation using ff1.5 at http:// > www.peepo.com/index.svg to see how we have attempted to meet 2.4.8. > use the 'tab' key to navigate, 'shift + tab' to go back through the > links. > Correction: your link is http://www.peepo.co.uk/index.svg . It's nice and I like the tabbing functionality. I don't like that it's in scripting and i understand why you are unhappy withthe lack of a spec for this in the w3c. However, I also think that this is best left to commercial interests to sort out as they see fit. If providers build junk, sales will sag. That's generally enough to push app developers to implement accessibility imho. You know my position that the accessibility guidelines can get totally out of control and that there will always be someone hurt by the help given to another person ("Document must offer brail solution", "Document must offer acoustic solution", "Document must work on an LCD without a microphone", "Document must provide same functionality to all users" ). So what do we do...? Do we build our systems for the lowest common denominator? Do we build improved systems that inevitably exclude some users? Do we legislate functionality into applications? If so, do we do it accross the board? If yes, why are we applying different standards to web apps than we apply to the physical press, public transportation, and vocal communication? Keep up the accessibility fight. Cheers, Ronan > regards > > Jonathan Chetwynd > Accessible Solutions > http://www.eas-i.co.uk > > **My install instructions for the dell latitude 433mc, which is > possibly one of the earliest colour(8) laptops to run linux, remained > at linux-laptops for many years! > This machine was never capable of running windows, but happily ran > tweaked linux games for our students in ~4Mb. > > On 19 Dec 2005, at 15:05, Ronan Oger wrote: > > Jonathan, > > > 1.1 "Ensure that the user can operate, through keyboard input alone, > > any user agent functionality available through the user interface." > > This capability already exists in all serious OS's, and adding this > functionality on Yet Another Layer will only create confusion where > none is > required. > > When we talk about keyboard events, we are talking about the > svg-document-level undersranding of the context of a keypress (such > as the > letter 'p' in the text-entry context). And I agree that SVG > implementations > need to address this. However, I also believe that this is best handled > through scripting (ie programatically) rather than declaratively. > > The idea of using key events to trigger mouse pointer events does not > need to > be part of this discussion because this is already handled at the OS > level > and because it is generally desirable to have consistent behaviour > accross > the entire window manager (MS Windows in your case, I presume). > > Adding this to the SVG app level will add nothing to usability and > will serve > only to make the SVG app architect's job more difficult. > > In Linux, for example, mouse and keyboard events can be linked > arbitrarily and > interchanged at will. Because of this, it is critical that an app > developer > not be able to arbitrarily impose their own mappings which may render > the UI > inoperable. > > It is simply not the job of SVG to know what the input methods are. > This is an > OS-level or user-inter-face-level problem. If we allow the SVG canvas > to have > different fundamental behaviour than the OS does, then we will cause > a rat's > nest of complications. > > I don't know how windows handles this, but in linux systems, if you > want to > use your keyboard(s) to define mouse events, it is a trivial problem. > > Presumably, windows XP is a reasonably well written application. Can > it not > handle arbitrary pointing device setups, including keyboard mappings...? > > Ronan > > On Monday 19 December 2005 09:25, you wrote: > > "Ensure that the user can operate, through keyboard input alone, any > > user agent functionality available through the user interface." > > > > Ronan, > > > > This distinctly is an SVG issue, which was drawn to your attention at > > our SVG meeting in London**. > > > > your quote* is an admission of error, not an exclusion, and it is > > important that this is acknowledged. > > Please refer to the SVG accessibility appendix H: > > http://www.w3.org/TR/2003/REC-SVG11-20030114/access.html > > and UAAG Guideline 1 in particular: > > http://www.w3.org/TR/UAAG10/guidelines.html#gl-device-independence > > > > 1.1 "Ensure that the user can operate, through keyboard input alone, > > any user agent functionality available through the user interface." > > > > I remain grateful to the firefox SVG team for resolving this matter > > in bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=259062 > > but have no control over their method. > > > > regards > > > > Jonathan Chetwynd > > Accessible Solutions > > http://www.eas-i.co.uk > > > > > > > > On 17 Dec 2005, at 19:38, Ronan Oger wrote: > > > > *"As in DOM2 Key events, the SVG specification does not provide a > > key event > > set. An event set designed for use with keyboard input devices > > will be > > > included in a later version of the DOM and SVG specifications." > > > > **There were many outcomes including: http://svg-whiz.com/BAM/#key- > > mapping and > > http://jan.kollhof.net/projects/svg/examples/focus.svg was in fact > > presented. > > -- > Ronan Oger > Director > RO IT Systems GmbH > ...Building Web2.0 with SVG since 2001 > > http://www.roitsystems.com > > > ----- > To unsubscribe send a message to: svg-developers- > [EMAIL PROTECTED] > -or- > visit http://groups.yahoo.com/group/svg-developers and click "edit my > membership" > ---- > > > > SPONSORED LINKS > Computer internet security Computer internet business Computer > internet access > Computer internet privacy securities Computer internet help How to > format a computer hard drive > > YAHOO! GROUPS LINKS > > Visit your group "svg-developers" on the web. > > To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > > > ----- > To unsubscribe send a message to: > [EMAIL PROTECTED] -or- > visit http://groups.yahoo.com/group/svg-developers and click "edit my > membership" ---- > > > > YAHOO! GROUPS LINKS > > > Visit your group "svg-developers" on the web. > > To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. -- Ronan Oger Director RO IT Systems GmbH ...Building Web2.0 with SVG since 2001 http://www.roitsystems.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/KIlPFB/vlQLAA/TtwFAA/1U_rlB/TM --------------------------------------------------------------------~-> ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
