- From: Schnabel, Stefan <stefan.schnabel@sap.com>
- Date: Fri, 14 Sep 2007 09:22:28 +0200
- To: "Victor Tsaran" <vtsaran@yahoo-inc.com>, <gibsonb@us.ibm.com>, <wai-xtech@w3.org>
- Cc: "Keim, Oliver" <oliver.keim@sap.com>
Hi Becky,
First, I would vote for focusable splitter elements in Toolkits.
Second, I think that a real accessibility-enabled control framework
should have full control over resizing and should not rely on external
technology functionality being present or not in an arbitrary OS /(no
MouseKey usage).
This would mean
- horizontal splitters are resizable using key arrow right/left
- vertical splitters are resizable using key arrow up/down
- default is say 10%
The resize steps are user-configurable e.g. in context menu or in the
accessibility options dialogue of the framework along with others (sound
schemes etc.)
This consequently requires that the framework offers such a thing :)
(which should be good style+practice in the long run)
For the current web docs the story may be different (resizing of HTML
frames with keyboard actually requires MouseKey usage).
But we should start thinking about the next generation ..
Regards
Stefan
-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Victor Tsaran
Sent: Donnerstag, 13. September 2007 22:48
To: 'Becky Gibson'; wai-xtech@w3.org
Subject: RE: [STYLE GUIDE] keyboard resizing of split containers
Hi Becky,
Wow, you surely bring some very complex issues to mind.
I would vote for resizing through menus for these reasons:
1. Discoverability -- easier to find.
2. Flexibility -- let developers assign custom shortcut keys since it is
going to be hard to standardize on this one and this is not an enough
frequently-used operation to reserve a keystroke for it.
3. Scalability -- through "10%", "25%" or whatever options, as you
suggested, we can save some users the number of actions they have to
perform
to resize any of the panes.
Regards,
Victor
-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf
Of Becky Gibson
Sent: Thursday, September 13, 2007 12:52 PM
To: wai-xtech@w3.org
Subject: [STYLE GUIDE] keyboard resizing of split containers
My definition of a split container is a section of the Web page which is
split into two or more sections either horizontally or vertically.
Split
containers can be nested to create both vertical and horizontal
sections.
A common implementation is for mail programs which usually provide a
tree
of folders on the left hand side of the page and on the right hand side
of
the page split into two sections stacked one above the other - one with
a
listing of the documents in the folder and another to preview the
contents
of the selected document. Most applications provide a grab point on the
border of the pane to resize the section using the mouse.
Is a keyboard mechanism to resize a split container required to meet
accessibility guidelines? I am assuming yes since unless there are
scroll
bars some content might not be visible without resizing.
I have some ideas for resizing with the keyboard.
1) Assign some key that when pressed when focus is within the section,
will move focus to the grab point. The user then modifies the size of
the
container using the mouse keys. This isn't particularly useful for
screen
reader users but I am hoping that they don't have to deal with the
sizing
problems because the screen reader will read all of the content even if
it
is clipped?
2) Assign some key that when pressed when focus is within the section,
will open a context menu with options for making smaller/larger by 10%,
25%, 50%.
3) Shift-F10 from within the section will invoke a context menu with
options for making the section smaller/larger by 10%, 25%, 50%, If an
application context menu for this section of the Web application already
exists, the resize items would be appended to it. This has the
drawback
that it is harder to implement, and will override the browsers context
menu if there is no Web application defined context menu. This could
create a scenario where the user can not invoke the browsers context
menu
because the entire page is made up of re-sizable sections. Of course
that
could also happen with any application defined context menu as well -
but
overriding the browser context menu just for resizing sections seems a
bit
harsh.
I prefer option 1, although it has the disadvantage of a "special" key
sequence that people will have to learn through discovery or good
documentation. But I also need screen reader user feedback to make sure
this is sufficient.
thoughts?
Becky Gibson
Web Accessibility Architect
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
blog: WebA11y
Received on Friday, 14 September 2007 07:26:32 UTC