Time zone selection is inefficient with keyboard and screen readers

[daniel-montalvo]

Time zone selection is inefficient with keyboard and screen readers

• Add new calendar event
• tab to the Time zone selector
• try to Enter a city name

Results are filtered out based on the string you typed, pressing down arrow moves to the first of these results. Currently, focus moves to the first list item that starts with the letter I first typed. IF there is no item that starts with the first letter I typed, nothing happens.

[mcking65]

I don't understand why we have a time zone picker with 432 items when there are only 24 time zones?

If we want to specify a city for the time, then please have two pickers: country and then city. Please don't combine country and city into a single combobox. Long lists where many consecutive items start with the same syllables are not a good experience for screen reader users. I don't imagine they are for others either.

[maryjom]

Even though I'm not a screen reader user, I have trouble with the long list of city/country as I never know which cities they might choose to have in the list. It would be nice to be able to pick by the name of the time zone. If you don't know the name of a time zone you can do an internet search for it using whatever information city/country you are familiar with there. Even using a name of a small town & state or city and country will yield a definitive result.

[LJWatson]

I wonder if listing by time zone with example/typical cities would work? For example GMT (London, Lisbon, Dublin), or PST (San Francisco, Los Angeles) and so on? I assume the calendar already handles daylight saving/summer time switching, so only the standard/typical time zones would be needed.

Whichever approach is taken though, simplifying or breaking down the time zone choice would make things easier.

[vivienlacourba]

Related issue w3c/calendar#96 cc: @jean-gui

[jean-gui]

This field contains time zones as described in the tz database, which I believe is the only time zone representation that allows us to accurately handle transitions such as summer time. Other representations wouldn't allow us to do that accurately or could be confusing. AFAICT, at least Thunderbird and Google Calendar use this standard as well.

Creating two fields seems sub-optimal: that's still two fields to search through, and some time zones are described with two regions and a city, America/Argentina/Buenos_Aires for example.

So my proposal is to make the time zone field use the same auto-complete pattern as group and invitee ones. I would also add more information such as the UTC offset and corresponding time-zone name (without summer time). We would end up with something like: (UTC+02:00) Central European Time - Europe/Paris. Such names would allow us to search by offset, location or time zone name. I could even add the time zone abbreviation, which can be ambiguous by itself (CST can mean China Standard Time, Cuba Standard Time or Central Standard Time) but would be fine with all the extra information.

How does that sound?

[mcking65]

@jean-gui

I'd like to see how that works. On the face of it, it sounds good. I am assuming that autocomplete matches any substring within the entire tz name.

The ability to type something like UTC-8 and getting only those options would be extremely helpful.

[jean-gui]

I have implemented the proposal, you can test it. The format is (GMT+02:00) Central European Time - Paris. I used GMT instead of UTC otherwise searching for the UTC time zone would be impossible. I have also removed the world region as I don't think it was very useful with the time zone name already there.
The field allows to search for any substring within those names, and also search for substring within the former name (Europe/Paris)