Custom Calendar: accessibility issues

[leandroalonso]

Our custom calendar has accessibility issues. Both when scheduling a post and when selecting a date range from Activity Log:

• Unavailable (future) dates are not announced as unavailable.
• Dates of the week ( S M T W T F S) are incorrectly announced: eg. F is announced as “half-F, night sky”
• While scrolling up and down announcements say “Page 138” which is not super helpful. Maybe we can announce something else, like the month visible on the screen?
• Month name in date picker cuts off when using large font

How to reproduce

1. Open Activity Log for any site with available filters
2. Using Voice Over, test the aforementioned items

Prioritised tasks from investigation

• [x] #17760
• [x] #17780
• [ ] Calendar accessibility: Prevent hidden Activity Type chip from grabbing VoiceOver focus when using the Activity Log date filter
• [x] Calendar accessibility: Add heading trait to month headings for navigation
• [x] Calendar accessibility: Make month headings show at larger dynamic type sizes on Schedule Post
• [x] Calendar accessibility: Make day numbers show at larger dynamic type sizes on Schedule Post
• [ ] Calendar accessibility: Make month headings show at larger dynamic type sizes on Activity Log
• [ ] Calendar accessibility: Make day numbers show at larger dynamic type sizes on Activity Log
• [ ] Calendar accessibility: Announce future dates as unavailable for selection when using the Activity Log filter
• [x] Calendar accessibility: Announce selected dates as selected
• [x] Calendar accessibility: Announce weekday for selectable dates, instead of as headings
• [x] Calendar accessibility: Announce current selection as a date range
• [x] Calendar accessibility: Give descriptive accessibilityLabels to the previous/next month buttons on Schedule Post
• [ ] Calendar accessibility: Announce month(s)/year(s) on screen when scrolling, not page numbers

[startuptester]

@shiki made excellent points about this. I want to highlight what he said about the importance of considering existing mental maps.

_I only know that we can ask VoiceOver to speak a custom message using UIAccessibility.post() with announcement. I’m not sure if we can turn off the automated VoiceOver announcement when scrolling. In any case, this would probably be a fairly custom implementation.

We also have to be mindful that when customizing a VoiceOver behavior, it may end up surprising regular VoiceOver users. Hearing “Page 1 of 132” may be something that they already expect and are fine with it.

My advice is that this is probably okay as long as there are appropriate heading accessibility traits so that the reader can navigate using headings by using the rotor. Navigating by headings is more useful than scrolling_. - @shiki

[joshheald]

I've done some investigation on this ticket, and wanted to share my thoughts before writing any code.

I've confirmed that the Calendar view is only used in Activity Log filters, and for scheduling a post's publishing time, as covered in the ticket.

Issues from ticket:

• Unavailable (future) dates are not announced as unavailable. ✅ These should only be unavailable in the context of the Activity Log date filter. They are announced as "{date} button", the same as any past date.
• Dates of the week ( S M T W T F S) are incorrectly announced: eg. F is announced as “half-F, night sky” ✅ There seems little value in announcing these at all as they are not headings linked to the dates, in VoiceOver.
• While scrolling up and down announcements say “Page 138” which is not super helpful. Maybe we can announce something else, like the month visible on the screen? ✅ Apple's Calendar app reads the first date visible in the scroll area when you scroll, instead of a page number: this seems like a good option to follow.
• Month name in date picker cuts off when using large font ✅ for the Activity Log filter view only. It does not change size in either the Activity Log filter, nor the post scheduling view.
• ...this is probably okay as long as there are appropriate heading accessibility traits [on the month headings] so that the reader can navigate using headings by using the rotor. ❌ The month headings don't have these traits, this navigation is not currently possible.

Further issues found:

Activity Log

• The hidden "Activity Type" chip from the presenting screen keeps grabbing focus, which makes it difficult to keep place and use the calendar.
• The selected range isn't clearly announced, and after selecting either or both date, they are announced as three separate labels, e.g. "8th December 2021" "hyphen" "17th December 2021". We could instead announce "Selected range: 8th December 2021 to 17th December 2021"
• Larger size Dynamic Type replace day numbers above 9 with ...

  Schedule Post

• Navigating with Next Item or Next Container to the dates causes it to jump to the first page, 1 January 1951
• Three-finger swipes to scroll back and forward between months works, but is not discoverable.
• Scrolling in this way announces pages by number, and would be improved by announcing the month/year.
• The previous and next month arrow buttons are announced as "button: {left|right} arrow", and could instead be "next|previous month".
• Month headings are visible with larger Dynamic Type sizes, but do not respond to them.
• The day numbers above 9 are truncated in this view too.

Data entry

Should we consider providing a text field to enter dates as a further enhancement here? It would require more validation than the calendar selection, but is a straightforward way to enter the value desired.

[joshheald]

Prioritised tasks

• Navigating to the first visible date button on the Schedule Post view, not 1 Jan 1951
• Prevent hidden Activity Type chip from grabbing VoiceOver focus when using the Activity Log date filter
• Add heading trait to month headings for navigation
• Make month headings show at larger dynamic type sizes
• Make day numbers show at larger dynamic type sizes
• Announce future dates as unavailable for selection when using the Activity Log filter
• Announce weekday for selectable dates, instead of as headings
• Announce current selection as a date range
• Give descriptive accessibilityLabels to the previous/next month buttons on Schedule Post
• Announce month(s)/year(s) on screen when scrolling, not page numbers

[joshheald]

@leandroalonso @startuptester I'd like your thoughts on something... The biggest accessibility improvement to be made here might be to use system controls where we can, or at least where the custom calendar control gives us little benefit.

On Schedule Post, we only allow the user to select one date and time. This makes it an ideal case for using UIDatePicker, which supports this out of the box. I notice the app supports iOS 13.0 and above. From iOS 13.4 onwards, we can use UIDatePickerStyle.compact which provides a text field that expands when tapped to show a calendar, with a time component too:

From iOS 14 onwards, we can use UIDatePickerStyle.inline, which would let us put that same interface in a slide up view as we have in the code at the moment, without forcing it to be in a popover.

For post scheduling, UIDatePicker would likely be better for both people using VoiceOver/Dynamic Type, who would not face the issues we're trying to resolve here. It would also be better for people not using those assistive technologies, as it would give quicker options for navigating to a specific date using the month/year dropdowns which are available in the system control.

We could either fall back to the standard wheels for iOS 13.0-13.3, or use the custom calendar.

For the Activity Log filter, I think we should keep the custom calendar for its benefits in visualising a range of dates. Those benefits are significantly reduced for VoiceOver users, so we could change the interface to use two UIDatePickers when VoiceOver is in use.

[leandroalonso]

The biggest accessibility improvement to be made here might be to use system controls where we can, or at least where the custom calendar control gives us little benefit.

I agree! 100% for using system controls. :)

From iOS 13.4 onwards, we can use UIDatePickerStyle.compact which provides a text field that expands when tapped to show a calendar, with a time component too:

How would that look like when publishing a post in the bottom sheet? The sheet would increase its size?

I'd focus on the post flow given it's one of the core flows of the app. If you have time left later, then we can tackle Activity Log. Wdyt?

[startuptester]

I agree! 100% for using system controls. :)

Agreed!

without forcing it to be in a popover.

I like this part, but I'm having trouble visualizing it.

How would that look like when publishing a post in the bottom sheet? The sheet would increase its size?

This Kudos to you for thinking about both sides of the accessibility coin in this decision 👍

[joshheald]

@startuptester @leandroalonso Sorry for the lack of clarity on this. Here's an example of the default .compact behaviour – there's no increase to the size of the sheet, it's a popover above the sheet.

https://user-images.githubusercontent.com/2472348/149976054-2ced132c-8367-4f9f-b602-65aeb8b7d069.mp4

From iOS 14+, we have the option of using .inline, which would be much more like the existing view, you'd need to tap through from the initial publish sheet to a screen with a calendar on it. It would just use a system control.

Personally, I quite like removing the taps through the hierarchy, as in the video above, and think we could use that regardless of iOS version.

[leandroalonso]

Personally, I quite like removing the taps through the hierarchy, as in the video above, and think we could use that regardless of the iOS version.

I think the number of taps in the current solution only requires a single additional tap but I get when you mentioned the hierarchy (not to take into account the accessibility, which is the whole reason behind these changes).

There's only one thing I'm missing in your example which I'm quite not sure how to solve. The original has an option to reset this change by tapping "Publish immediately".

Any suggestions on how we would add this same feature here?

[joshheald]

I think the number of taps in the current solution only requires a single additional tap Yeah, agreed, it's not a lot less taps (unless you are changing the month quite a lot, which is unlikely for this use case!)

The original has an option to reset this change by tapping "Publish immediately". Any suggestions on how we would add this same feature here?

With it in the cell, as per the video, the only thing I can think of is a cell swipe action, which is a bit hidden. We could spread the Publish Date over two rows, giving space to include a "Publish immediately" or reset type button...

[startuptester]

I really love this idea.

a cell swipe action, which is a bit hidden.

Agreed, I definitely don't think we should go that way.

over two rows, giving space to include a "Publish immediately" or reset type button

Does it have to be a in a separate row? Is something like an undo icon/button beside the time field not feasible?

[joshheald]

Having just checked a smaller device, it will need more space regardless, because on the smallest devices the date picker already crashes in to the label. This will also be present (and worse) on larger devices when Dynamic Type is set to larger sizes.

I think an undo/clear button will work well though. I'm going to see what I can do with dynamically resizing the row to make it double height when it needs to be, and include a 🅧 button when there's a value set, i.e. allow people to reset to "publish immediately."

[startuptester]

I was thinking more like an undo icon, like ↩️ to signify that it will reset to default, rather than clear the field.

Other than that, it sounds good! Nice call on the screen sizes. 👍

[joshheald]

@startuptester @leandroalonso Closing the loop: #17799 changes this to use the UIDatePicker.inline on iOS 14 and above. Unfortunately, I wasn't able to get the approach above with the date picker in the cell to work well on all the different devices, it was just too constrained and AutoLayout was not my friend.

I hope you agree that the implementation I've gone with is still an improvement for those on iOS 14 and above, particularly in terms of accessibility.

[joshheald]

I'm going to drop this issue now, since my rotation has ended, but there's more stuff to do here when someone else has time to jump into it 😊

To whoever does pick this up: I'm more than happy to chat through the issue if that would be helpful.