Loading ...
Sorry, an error occurred while loading the content.

Re: [svg-developers] Firefox 1.5 with SVG now officially released

Expand Messages
  • Robin Berjon
    ... Congratulations and many deeply heartfelt thanks to the FF SVG team! We know how hard it can be to implement SVG, especially with support for inlining
    Message 1 of 49 , Nov 30, 2005
    View Source
    • 0 Attachment
      On Nov 30, 2005, at 04:49, Andreas Neumann wrote:
      > It seems like Mozilla Firefox 1.5 with native SVG support is now
      > officially released!

      Congratulations and many deeply heartfelt thanks to the FF SVG team!
      We know how hard it can be to implement SVG, especially with support
      for inlining inside other XML vocabularies and building on top of an
      existing system, and you've done a brilliant job.

      You guys rock the Web,

      --
      Robin Berjon
      Senior Research Scientist
      Expway, http://expway.com/
    • Jonathan Chetwynd
      Ronan, it would be great to see examples of some of your accessibility solutions for SVG, perhaps you could post links with comments? As Chris points out, SVG
      Message 49 of 49 , Dec 22, 2005
      View Source
      • 0 Attachment
        Ronan,

        it would be great to see examples of some of your accessibility
        solutions for SVG, perhaps you could post links with comments?
        As Chris points out, SVG would benefit from an accessibility
        techniques document.

        regarding meta-data labelling of SVG, http://www.peepo.co.uk uses
        reasonably extensive RDF descriptions of GUIs, can you perhaps point
        to an example that you consider relevant?

        cheers

        Jonathan Chetwynd
        Accessible Solutions
        http://www.eas-i.co.uk



        On 19 Dec 2005, at 23:04, Ronan Oger wrote:

        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-
        > unsubscribe@yahoogroups.com
        > -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:
        > svg-developers-unsubscribe@yahoogroups.com
        >
        > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        Service.
        >
        >
        >
        >
        >
        > -----
        > To unsubscribe send a message to:
        > svg-developers-unsubscribe@yahoogroups.com -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:
        > svg-developers-unsubscribe@yahoogroups.com
        >
        > 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


        -----
        To unsubscribe send a message to: svg-developers-
        unsubscribe@yahoogroups.com
        -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:
        svg-developers-unsubscribe@yahoogroups.com

        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      Your message has been successfully submitted and would be delivered to recipients shortly.