Re: [DHTML Style Guide] Proposed Dialog Behavior

Small edit dealing with the application logic underlying
the access provisions -- not the access provisions themselves.

On 26 Feb 2008, at 11:03 AM, Becky Gibson wrote:
> There must be a method to close the dialog without taking any action.

For our dialog, reduce this must to a should.

This is a constraint on the state chart of the dialog.
It cannot always be satisfied, as when there has been
an exception raised deeper in the system and the user's
choice is a matter of what recovery path to seek, there
is no way to restore the prior state per_se.

This doesn't only happen in the OS.  If there is an
error detected on the server, the script may have to
present "how to handle this exception" choices to a
user in an AJAX application dialog.

> Modal Dialog
> A modal dialog is a dialog that takes and holds focus until the  
> dialog is
> closed or submitted.
> When a modal dialog opens focus goes to the first focusable item in  
> the
> dialog.  Determining the first focusable item must take into account
> elements which receive focus by default (form fields and links) as  
> well as
> items which may have a tabindex attribute with a positive value.   
> If there
> is no focusable item in the dialog, focus is placed on the dialog
> container element.
>
> There must be a method to close the dialog without taking any  
> action. This
> could be implemented via a cancel button which is keyboard  
> accessible.  It
> is recommended that a dialog also be cancelled by pressing the  
> escape key
> with focus on any item.   If the current focus item has escape key
> behavior, the press of the escape will be handled by the current  
> item and
> the user may have to press escape an additional time to close the  
> dialog.
> If the purpose of the dialog is to gather information, the dialog  
> should
> have a mechanism to submit the data gathered usually via a keyboard
> accessible button. When the dialog is closed or cancelled focus should
> return to the element in the application which had focus before the  
> dialog
> is invoked.  This is usually the control which opened the dialog.
>
> Focus must be held within the dialog until it is cancelled or  
> submitted.
> As the user presses tab to move within items in the dialog,  
> pressing tab
> with focus on the last focusable item in the dialog will move focus  
> back
> to the first focusable item in the dialog.   Likewise, if the user is
> shift-tabbing through elements in the dialog, pressing shift-tab with
> focus on the first focusable item in the dialog will move focus to the
> last item in the dialog.  Even if the user clicks outside of the  
> dialog on
> the application which invoked the dialog, focus remains in the dialog.
> Because the dialog is modal and the user can not interact with the
> invoking application while the dialog is displayed, there is not a
> requirement to make the dialog moveable via the mouse although this
> behavior is recommended.
>
> Non-Modal Dialog
> A non-modal dialog is one which is displayed and focusable at the same
> time as the application which invoked it.  Like the modal dialog there
> must be a mechanism to cancel the dialog without taking any action  
> and a
> keyboard accessible method to submit any data gathered in the dialog.

I believe that the 'wizard' proposal is a special case of this
dialog category.

We should use shared definitions and terms for the 'go' action and the
'no-go' action between these two sections of the Style Guide and Best  
Practices.

  - 'go' is like confirm, accept, place order, ...
  - 'no-go' is like deny, decline, cancel, ...

> Also like the modal dialog, focus via the tab and shift-tab key  
> must be
> maintained within the dialog. However, a non-modal dialog should  
> have a
> keyboard mechanism to return focus to the application while leaving  
> the
> dialog open.  The F6 key is the recommended key to move focus  
> between the
> application and an open model dialog.  The mouse user may click on  
> either
> the application or the dialog to change focus between the two.  In  
> a Web
> application the non-modal dialog is usually always displayed above the
> application page, rather than in a separate browser window but that  
> is not
> a requirement.
>
> Accessible drag and drop techniques (note - this is a big hole as the
> DHTML team doesn't have a recommendation completed for drag and  
> drop, yet)
>  should be implemented to allow the non-modal dialog to be moved  
> via the
> keyboard or the mouse.

[just checking where the hole is...]

The behavior is described at
http://www.w3.org/TR/wai-aria-practices/#dragdrop

Does the Style Guide caucus need more than this as a basis
for discussing key choices?

> Tooltip Dialog
> Dojo also has an additional type of dialog called a tooltip dialog.  I
> don't know if the DHTML style guide group wants to address this  
> type or
> not.
> A tooltip dialog is a modal dialog that is rendered near the invoking
> element and visually connected via a cartoon bubble-like  
> protrusion.  The
> tooltip dialog is closed by pressing the escape key when focus is  
> within
> the dialog, mouse clicking on a close icon, or mouse clicking  
> outside of
> the dialog onto the application.  It is modal because focus is trapped
> within the dialog as the user navigates via the tab and shift-tab key.
> Unlike a true modal dialog, the user can click outside of the dialog,
> however in that case the tooltip dialog is immediately closed. A  
> tooltip
> dialog can not be moved/dragged.  Other than the close and move  
> behavior,
> all other behaviors of a modal dialog are implemented by the tooltip
> dialog.

The tooltip role in the WAI-ARIA vocabulary

http://www.w3.org/TR/wai-aria/#tooltip

.. despite its description in the draft document, is intended to
include dialog cases where the tooltip functions like
a sub-menu attached to an object, even 'though the object itself is
not a menu item.

I am not sure whether the 'capture the focus navigation' modal quality
that you describe above is always true of these active tooltips or not.
Please discuss.

>
>
>
> 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, 26 February 2008 16:44:18 UTC