Re: [STYLE GUIDE] keyboard resizing of split containers

I like the idea of following convention as Earl describes. I've 
reconsidered my stance on putting the splitter grip in the tab order as 
that could be frustrating if the tab order is overcrowded and a keyboard 
user wanted to do a quick resize.

cheers,
David

Earl Johnson wrote:
>
> Hi Becky;
>
> I'd prefer not having to use resize menus.
>
> On Windows desktop/MFC components F8 is the apparent default with the 
> arrow keys then resizing and enter stops resizing. Tab and Shift+Tab 
> [along with F6 I think] move input focus to the next/previous pane.
>
> My questions:
> 1. Can F8 be used to focus the splitter bar?
> 2. Retaining the "discreet steps" method from the menus, can you 
> instead make each let press jump 10% or 10% -> 25% -> 50% -> etc.?
> 3. Can you make home, end, pgup/dn [the bigger jump keypress] work also?
>
> This would make access and control of the splitter follow how it's 
> implemented in the Windows MFC, Java JFC, and Motif UI Toolkits [at 
> least]? Or do browsers already use this [I'm not sure I've seen one in 
> a browser before].
>
> Earl
>
>
> Becky Gibson wrote:
>
>> 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 Saturday, 15 September 2007 02:19:15 UTC