Re: ISSUE: [Fwd: Editable: (trivial) SVG 1.2 May 2004 draft]

[Bcc User Agent Accessibility Guidelines working group]

<quote who="Chris Lilley">
> On Saturday, August 14, 2004, 5:43:27 PM, Jon wrote:

> JF> I think I agree with Charles. In my view, the spec should say
> something like:
>
JF> "User agents MUST support keyboard navigation facilities within editable
JF> text, such as arrow keys to move the current caret position left and
right.
JF> It is STRONGLY RECOMMENDED that the keyboard navigation facilities be as
JF> compatible and rich as the system's standard keyboard navigation
facilities."
>
CL> Yes. I think that Home/End should be examples, and Cut/Copy/Paste is a
CL> function not (necessarily) a key.

Indeed. I want my telephone to support this, but it doesn't have a HOME
key. (It doesn't have a very well designed keyboard interface either, but
that's theri fault. It isn't unreasonable to hope they will produce one in
a revision...)

I think there may be an accessibility issue if you don't support the
system-dependent navigation functions - although I think the User Agent
group are the ones who would be able to say how seriously they categorise
that. So I am not sure if STRONGLY RECOMMENDED is enough, or if it is
better that User agents MUST support at least system-dependent methods.

I agree with Jon that it is important to allow support of other paradigms
- Opera has a different and more useful approach to keyboard navigation
than other browsers, but that is as well as supporting system conventions.
As another example, in Amaya there are several ways to activate the
endOfLine function, including the relevant system-based key and a command
that is common to Amaya cross-platform.

Cheers

Chaals

-- 
Charles McCathieNevile           charles@sidar.org
                 http://www.sidar.org

JF> My thinking is that sometimes user agents will want to implement keyboard
JF> navigation facilities that are compatible with the window system (e.g.,
JF> Windows-compatible keyboard navigation when running on Windows), but in
JF> other situations user agents might want to achieve compatibility with
some
JF> sort of cross-platform, system-independent metaphor. For example, HTML
JF> pages, Flash pages, and PDF pages (and same with SVG!) all have some
JF> notions of system-independent UI, and I think we should include enough
JF> weasle-wording to allow user agents a little bit of flexibility, which is
JF> which I said "STRONGLY RECOMMENDED" instead of "MUST".

JF> In particular, I think the SVG specification has no business specifying
JF> HOME key processing within an editable text field. Even if most
JF> environments use the HOME key to go to the beginning of the text edit
JF> field, I will bet there is at least one platform where the HOME key has
JF> some other behavior (i.e., scroll the whole document to the top, jump to
JF> the start of the current line within a multiline text field, etc.)

> At 06:51 AM 8/14/2004, Robin Berjon wrote:
>
>>>Hi,
>>>
>>>I think this is indeed an issue, but it should be trivial to fix (make
>>>them all system-dependent).
>>>
>>>-------- Original Message --------
>>>Subject: Editable: (trivial) SVG 1.2 May 2004 draft
>>>From: Charles McCathieNevile <charles@sidar.org>
>>>To: www-svg@w3.org
>>>
>>>Hi,
>>>
[snip snip]
>>>Why are some of the keys specified, and others left as
>>> "system-dependent"?
>>>It would seem better to specify for each that the functions must be
>>>available, and must be activated by the system-dependent functionality.

Received on Sunday, 15 August 2004 05:33:10 UTC