Re: [STYLE GUIDE] keyboard resizing of split containers

Hi;

Forgot words in a couple spots but wanted to just update #2 below 
with my missing words because it's the most critical one. The 3 
questions now become:

1. Can F8 be used to focus the splitter bar?
2. Retaining the "discreet steps" method from the menus, can you 
instead make each press <of an arrow key> jump 10% or 10% -> 25% 
-> 50% -> etc. <instead?
3. Can you make home, end, pgup/dn [the bigger jump keypress] 
work also?

Earl


David Bolter wrote:

> 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 Tuesday, 18 September 2007 17:54:00 UTC