* Inline StatusRowView accessibilityLabel modifier
By inlining this label, we avoid the creation of `ConditionalContent`, which often leads to views being recreated unnecessarily.
In focused mode, the empty label is not read as, it is the accessibility container label for the post component elements.
* Inline StatusRowView accessibilityLabel modifier
By inlining this label, we avoid the creation of `ConditionalContent`, which often leads to views being recreated unnecessarily.
In focused mode, the empty label is not read as, it is the accessibility container label for the post component elements.
* Wrap
---------
Co-authored-by: Thomas Ricouard <ricouard77@gmail.com>
* Combine `joinedAtView` into one accessibility element
Previously, the calendar image was visible with a nonsensical label.
We use the `.combine` operator here to maintain the proper string formatting of the date.
* Improve the accessibility of the AccountDetailHeaderView
Previously, this image had no description and no indication that it had an associated interaction. Now, we wrap it in a button that performs the tap gesture action, and remove the element altogether if there is no avatar image set.
This commit also handles the checkmark for supporter users
* Tweak accessibility of Profile CustomInfoLabels
This commit:
- Reverses the order of title and value
- Sets the value as an `accessibilityValue`
- Adds a hint indicating what the button does, as they perform slightly different actions
* Make Profile tab header image into a Button
This element has an action associated with it (quicklook), so it makes more sense to have it as a button, and hide it if the user does not have an image set.
Without the action it would have been considered decorative and should be hidden.
* Change accessibilityLabel of Profile tab nav bar item to ‘Options’
“More” is considered overly generic.
This commit also adds two additional user input label options
* Add accessibility labels for the Profile tab `Picker`
Previously, these labels were the default accessibility label provided by the SF symbol, that almost, but not quite, made sense
* Remove StatusRowView swipe actions if VoiceOver is running
These swipe actions are automagically added to the accessibility element’s custom actions, in addition to the ones already there, which means that there is a significant (and confusing) amount of doubling up going on.
* Fix typo in StatusRowView.accessibilityActions
* Add accessibilityLabels to all StatusRowActionsView actions
* Provide explicit combined accessibility label for unfocused StatusRowView
Previously, this was a synthesized label, which read the elements in their traversal order, and didn’t provide any context for which of the three numbers corresponded to replies, boosts or favourites.
Now, we create an explicit combined label when the post isn’t being viewed by itself.
* Improve accessibility of StatusRow(Reblog|Reply)View
They are now combined elements and don’t vend the icon as its own element.
* Add missing punctuation to accessibility hints
* Remove interaction from Profile tab @username and profile note elements
These elements open the profile photo url, which is already provided explicitly through the profile photo
* Prefer spoiler warning for StatusRowView accessibility label
…but place the full, unredacted content in an `AccessibilityCustomContent` field for easy access.
Additionally, if VoiceOver is running, an action to expand the warning is also available.
* Represent `FollowButton` elements as Toggles to accessibility
Since these buttons have two states (though arguable in the case of following, but handled here by not changing the representation if a request is pending), it makes sense to handle them as toggles, so they will be read as “Following, On, <Trait>”
* Remove errant comment
* Add “Verified” accessibilityValue to profile fields
* Fix bug StatusRowView default action bug affecting VoiceOver users
Previously, the default (‘Activate’) action for VoiceOver users would be to share a link to the toot, rather than navigate to its detail. It’s hard to say exactly what caused this, but the root was the inclusion of the `contextMenu` in the `accessibilityActions`.
Now, double-tapping on a a non-focused `StatusRowView` will take you to the toot detail.
* Add header trait to Profile tab display name and familiar followers
These stand out as being header-like in presentation and represent the beginning of specific parts of the screen.
* Add conditional accessibility modifier to Profile tab user-defined fields that opens the correct link
* Add accessibility container that contextualises the user-defined fields
When VoiceOver users first enter a user-defined field, the container label will be read out before the element’s spoken description.
* Improve StatusRowView combined accessibility label
It will now start with:
“X boosted Y”, “X replied to @Y”, or “X…” depending on the context of the toot.
* Change familiar follows thumbnail to a Button; add display name as accessibility label
Previously, this button had no context, and would just be a series of images with nothing to allow users to disambiguate them.
* Revert changes from ZStack with tap gesture to Button
Using a Button for this purpose caused high weirdness in tap zones. Basically everything down to the familiar followers triggered both image buttons.
* Add image alt text to StatusRowView and StatusRowMediaPreviewView
Previously, there was no way for the intended audience for the alt text to find said text. There is a tap gesture on each image in the focused status row, but this is not advertised to the user.
Now, the first image’s alt text is read as part of the non-focused, combined representation, and each image has its own alt text attributed in the focused representation.
* Add Profile tab accessibility labels to indicate private/bot/muted/blocked accounts
Previously, the icon did not have any accessible representation (an empty text string).
* Add header trait to Profile “pinned post”
* Use the Account.Field.name for the user input label
* Replace spaces with commas in StatusRowView.combinedAccessibilityLabel
The bio (note) of an account can now be translated via DeepL. If the user has
put in his own DeepL API key, that is used, otherwise, the standard one is
used. See #1267
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Add localized label for the AI prompt status accessory view
Previously, this icon would have an accessibility label matching its SF symbol key, ‘faxmachine’.
* Darken status editor character count foreground color
By changing it to .secondary, it gets to an APCA contrast of 61, which is a _just_ passing Bronze score for that text size.
It’s still quite short of WCAG 2.1 AA at 3.3:1 (recommended is 4.5:1)
* Change remaining character count color to red when < 0
* Refine remaining character count accessibility
In this commit, we
- Change its trait to `.updatesFrequently`
- Set a localized `accessibilityLabel`
- Set its `accessibilityValue` to the remaining character count
- Disable user interaction (which is presumably set automatically by virtue of being enclosed in a `Menu`)
* Set accessibilitySortPriority on Status editor ScrollView
Previously, the traversal order placed the elements inside the `ScrollView` last. Now, they follow on from the navigation bar contents in the expected order.
* Hide the AvatarView from status creation accessibility
When there is only one account available, there is no functionality associated with this element, so it is considered decorative-only, and should be hidden
* Set TextView placeholder’s `accessibilityValue` to placeholder text when empty
This behaviour matches `UITextField`
* Hide TextView custom `placeholderView` from accessibility
Previously, TextView would vend two accessibility elements when the placeholder was visible. This causes needless confusion for users.
Now, the TextView matches the accessible behaviour of text inputs elsewhere.
* Improve accessibility of post `privacyMenu`
Previously, it would be presented as `Everyone, Button`. Now, we move the visibility to its `value` and use `Visibility` for its label, in conjunction with a hint that states it `Changes post audience`.
* Add `.button` trait and accessible label to emojis in `customEmojisSheet`
Previously, these would all present as `image` with no description, making it very hard to discern what kind of emoji you were adding.
* Change drafts sheet item type to `Button`
A button with an action has a more accessible representation than a `Text` with a tap gesture.
* Remove `.button` trait from `Link`s on Account Settings screen
SwiftUI currently sets both the `.button` and `.link` traits on these elements, which is a failure for WCAG 2.1 4.12: Name, Role, Value: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html
There is a radar for this issue: FB11507660
* Improve accessibility by making `AppAccountView`s a Button
Previously, the component elements of the `fullView` would be rendered as 3-4 individual views that would _all_ be interactive and perform the same action.
Now, as a Button, only one accessibility element is vended.
* Fix account label color
---------
Co-authored-by: Thomas Ricouard <ricouard77@gmail.com>
Previously, the button was shown if the always use DeepL setting was active.
This is redundant. Instead, the button is now shown, if the setting isn't
active.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Allow forced translation with DeepL
Translation with DeepL can now be forced either per post or on the system level.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Require the use of a private API key
A private API key of the user is now required to allow "always translate via
DeepL".
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Persist a stored API key
An API key is stored even if useOnlyDeepL is disabled. If the API key is empty,
the setting is still disabled.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Localize the texts
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Save API key while writing
The API key is now saved, even if the app is closed before leaving the
translation settings view.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Fix build
* Fix theme
* Transition to KeychainSwift, clean up
KeychainHelper is replaced with the already-used KeychainSwift package, the
functions are cleaned up so that the process is easier to understand. The
deactivateToggleIfNoKey function doesn't change the behavior of the buttons or
context menus in the timeline, only demonstrates the necessity of an API key to
the user. Consequently, it's only called when the settings view is shown.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Swiftformat + fixes
---------
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
Co-authored-by: Thomas Ricouard <ricouard77@gmail.com>
