* 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>
