Re: Updated: Date Picker Widget

Here's the comments on the date picker that I managed to jot down and we
didn't get to on today's call:

- On saying what AT should say.
What Chris gave us is a good walkthrough of a "for instance."  That  
is normally
where one starts.

Blue sky solution:
The architecture that I have in mind for this is that there an  
intermediate
'model' information pattern which defines some sort of "tapered  
prompt" structure
with content that supports varying verbosities of readout and  
probably has a precedence
grading in criticality.  The readout is controlled by the AT per  
disability class
defaults and personal preferences.  For example for the speed-burning  
screen
reader you would want a front-loaded reading order while for the  
dyslexic you
would be better to put the information into a full, natural sentence  
with the critical
terms accentuated.

The coding standards for web content define the
tapered-prompt information pattern and the query that loads this  
pattern from
the markup medium.  Compare with how we have given a search-list of  
acceptor
patterns for accessible name.

See role:nameFrom at http://www.w3.org/TR/wai-aria/#Properties

- Should the UI leap to a modal dialog on field error?

[Modal dialogs are a bete_noir with me.]

In my ideal world it is a user-preference policy item as to whether  
field
errors have to be dealt with instantly or the user has to acknowledge an
error condition to proceed or whether they should be able to go, fill in
the other fields that they are sure of, save their work, research the
error fields, and return and fix the problems.

So I would have qualms about the design specifying that attempting
to select an unavailable date should throw you into a modal dialog.
Another reasonable behavior is that you get a exception event (sonicon
and flash-if-showsounds), the date does not take on the selected state,
and an alert-but-not-alert-dialog is posted associated with the date  
that
the user erroneously attempted to pick.

In other words, avoid context changes where possible.

- localisation (footnote) and internationalisation (properly typed data)

One of the international realities is that all dates are indeterminate
without a time or at least a time zone.  And vice versa.

In lots of dialogs the user doesn't have to be confronted with the
generality of the full world-time model.  For example if you pick
a departure city first, then the time zone is known already from the
context of the date picking.

There was some discussion that the key for moving among months might
have to be localised.  The internationalisation response is that the
data must in all cases by properly typed with datatype(s) that binds
unambiguously to the ISO standards.

This means that "what it does" in terms of "next month" is stable across
language domains, and needs to be well-defined from the markup data.   
"Next
month" is uniquely and unambiguously defined by the 'month' concept in
the Gregorian calendar and 'next' is also implied
by this with the rule that Month 1 of year N+1 follows month 12 of  
year N.
Then you can show examples that are coded without a localization layer
and work with ISO keyboard and Gregorian calendar and just put the
footnote that keys and labels may be localized *but* that the resulting
data should always be bound to Gregorian date and UTC time in a way  
that can
be mechanically recognized by software processors.

FWIW

Al

On 25 Mar 2008, at 1:51 PM, Chris Blouch wrote:
> Update 3/25
> - added announcing number of days selected when switching from  
> Month to Month or Year to Year
> - added announcing availability of the selected date to the spoken  
> description
> - added announcing the month and its attributes when the user  
> crosses a month boundary
> - clarified combinations allowed for availability and selected
> - added implementation detail about supporting a passed in list of  
> unavailable dates
> - added section about navigation into the past
>
> Update 3/4
> - added commentary about alignment with mainstream objects
> - added section of additional keys we might want to consider
> - added continuity of grid focus when changing months and years
>
> Here is how I imagine an ideal Date Picker widget would behave.
>
> Purpose:
> Choose a date as input in an easy to navigate manner.
>
> Behavior:
> Like other widgets the calendar widget receives focus to become  
> active by tabbing into it. Once focused is received focus is  
> repositioned on todays date in a grid of days and weeks. I suggest  
> a grid as a reasonable representation because I am an advocate of  
> using the same representational metaphors for both visual and aural  
> navigation when it would not be overly cumbersome. This gives extra  
> lift to the solution by aligning it with mainstream objects.
>
> The spoken text for a single day is spoken from specific to general
>
> [Selected][Not Available] 4 Tuesday March 2008 [Not Selected] 
> [Available]
>
> As the user navigates they can quickly hear the number and if they  
> allow speech to go on long enough they can get the day or more  
> detail. If the date is already selected that is stated. If not then  
> "Not Selected" is stated at the end. The assumption is that being  
> selected is important to the user so they would want to know that  
> right away. The majority of dates are not selected so hearing that  
> over and over would be tedious, but still important at points of  
> interest. So the first focus on today's date would read all the  
> details out in full unless the users starts interacting. The widget  
> should also recognize some dates as not actually being available  
> such as weekends or holidays. These dates are announced as Not  
> Available or Available as appropriate. We announce Not Available  
> early on so the user knows to just skip forward to another date.  
> Obviously some combinations are not reasonable. Allowed  
> combinations are
>
> Selected Date
> Date Not Selected Available
> Not Available Date
>
> Arrowing up and down goes to the same day of the week in the  
> previous or next week respectively. If the user advances past the  
> end of the month they continue into the next or previous month as  
> appropriate. Visually the grid might flip from month to month but  
> audibly arrowing is a continuum of dates. When passing the epoch of  
> one month to another, the month entered should announce
>
> <Monthname><"NO"|XX> days selected.
>
> Going left and right advances one day to the next, also in a  
> continuum.  Visually focus is moved from day to day and wraps from  
> row to row in a grid of days and weeks.
>
> Pressing the enter key selects a date. There is no particular  
> reason a user can't pick more than one date but actual  
> implementation should include the option to allow only one choice  
> which deselects the previous choice. In this scenario there should  
> be an alert that says
>
> Selecting this date will unselect 4 Tuesday March 2008
> Ok Cancel
>
> For faster navigation there are also shortcuts to advance month to  
> month. I suggest control+alt+M. All the desktop/OS examples I  
> checked required the user to activate a modality such as weekly or  
> monthly view such that arrows would advance in steps of the mode's  
> current time unit. I think that is overly complex. control+alt+M to  
> advance a month and control+alt+shift+M to retreat a month. In  
> general the control+alt realm of keys is becoming more common in  
> web apps because of collisions with existing OS/Browser keyboard  
> shortcuts. When advancing or retreating a month it should read
>
> <Monthname><"NO"|XX> days selected.
>
> Likewise years can be advanced or retreated via control+alt+Y or  
> control+alt+shift+Y respectively. When advancing or retreating a  
> year it should read <Year><"NO"|XX> days selected.
>
> When changing months or years there is a question of where focus  
> should be in the grid after the change. I suggest that it should  
> stick to the week and day as the user cycles through months or  
> years. For example, if they are currently focused on 4 Tuesday  
> March 2008 and I advance a month, I should sill be on the first  
> Tuesday but in April, which is April 1. This new date should be  
> announced to the user.
>
> I was thinking we did not need another shortcut for changing weeks  
> because it is already just hitting the up and down arrow.
>
> I'm assuming there would be a header to the widget containing  
> equivalent links to advance and retreat years and months along with  
> the title showing which month and year the last focused date is  
> contained in. To reach the header the user would shift+tab. Shift 
> +tab takes you out of the calendar date picker section and moves  
> you through the month and year increment/decrement controls. If the  
> last control is reached and shift-tab is pressed again the widget  
> is exited "out the top". If the user tabs forward through the  
> widget and back to the date picker section, one more tab exits the  
> widget "out the bottom".
>
> {alternate}
> Some calendar widgets represented the current Month and Year as  
> pull-down menus in the header with the current month/year selected.  
> You then use standard navigation to change the selected month or  
> year from these menus.
>
> {alternate}
> Some calendar widgets have the year as an editable text field so  
> the user can just type in 2018 to jump to that date rather than  
> incrementing or messing with a menu.
>
> I'm not clear as to whether either of these alternates is better  
> then my original suggestion which was just plain header text with  
> controls to increment or decrement. Might swing to far on the  
> capability/complexity trade off.
>
> {additional keys}
> There are many other keys defined in some desktop applications but  
> I didn't know if they are of great utility or not. More keystrokes  
> is more cognitive load and more client-side code. That said, here  
> is a list of additional keystrokes beyond the baseline previously  
> discussed
>
> control+alt+home - first day of the current week
> control+alt+end - last day of the current week
> control+alt+pageUp - first day of the current month
> control+alt+pageDown - last day of the current month
> control+alt+t - Jump focus to today
>
> {Navigation into the past}
> If the widget is instructed to make all dates in the past  
> unavailable, if the user attempts a navigation method that would  
> take them into the past, the command is ignored and the user is  
> take to Today's date. Tody would announce
>
> "Dates in the past are not selectable"
>
> in addition to the regular information about that date.
>
> {widget implementation detail}
> While not a keyboard best practice, a good implementation should  
> have some method to pass in days to block off either by days of the  
> week or a list of dates. There should also be an option to make all  
> dates in the past unavailable.
>
> I purposely did not cover selecting time ranges. Most  
> implementations I've seen on the web have this as a separate UI  
> element such as pull-down menus for start stop points or  
> generalizations such as "morning" or "afternoon." This may be  
> because many time selectors are implemented as draggable regions  
> which has been difficult to duplicate in a web-based UI. It also  
> implies some measure of data entry and storage to label what this  
> particular time range is for, which gets pretty far into  
> implementation details.
>
> Looking forward to your analysis of the proposal.
>
> CB
>
>

Received on Tuesday, 1 April 2008 17:36:50 UTC