Page MenuHomePhabricator

Remove truncating on largest accessibility font sizes
Open, LowPublic

Assigned To
None
Authored By
Tsevener
Apr 20 2021, 5:38 PM
Referenced Files
F34622521: Group 146.png
Aug 27 2021, 11:28 PM
F34622531: Group 151.png
Aug 27 2021, 11:28 PM
F34622560: Group 154.png
Aug 27 2021, 11:28 PM
F34622467: Group 140.png
Aug 27 2021, 11:28 PM
F34622502: Group 141.png
Aug 27 2021, 11:28 PM
F34622496: Group 140.png
Aug 27 2021, 11:28 PM
F34622461: Group 137.png
Aug 27 2021, 11:28 PM
F34622513: Group 144.png
Aug 27 2021, 11:28 PM

Description

Why are we doing this?

To be fair to those who need it, we should not allow truncating of labels for those with the largest accessibility dynamic type sizes set. Apple encourages wrapping and changing layout directions (which should be easy with stack views) if needed to show the whole label.

Feature job story

As someone who utilizes the largest accessibility dynamic type sizes set, I want to be able to read all of the text available in the app and not see content truncated, so that I am not missing information when reading or navigating on the app.

Design needs
  • Complete an audit of where truncation currently occurs on the app at different dynamic type sizes
  • Propose solutions that do not include truncation

Figma file
Figma file of audit and proposed solutions can be found here.

General recommendations for largest accessibility dynamic type size include...

  • Text truncation
    • Keep text truncation to a minimum.
    • Avoid truncating text in scrollable regions unless people can open a separate view to read the rest of the content.
    • Display as much useful text in the largest accessibility font size as you do in the largest standard font size.
    • Prevent text truncation in a label by configuring it to use as many lines as needed to display a useful amount of text
  • Layout
    • Adjust layout at large font sizes
    • When font size increases, inline items, and container boundaries can crowd text
    • With large font size an inline layout might cause text to truncate so consider using a stacked layout where the text appears above the secondary items.
    • With multiple columns of text consider reducing the number of columns when font size increases
  • Glyphs
    • Increase the size of meaningful glyphs as font size increases

When dynamic type is not possible use large content viewer

  • More info be found under this ticket T280710
The audit

The audit includes not just truncated text but other issues found with the largest accessibility dynamic type. All issues are briefly mentioned and shown in the table below. More info. and examples can be found in the Figma file under the 'Text truncation' page.

TopicProblem areaSolutions on native iOS appsProposed solutions
Text truncationText truncation in places where the user should be able to read the whole text
Group 151.png (667×800 px, 111 KB)
Follow the above-mentioned recommendations under 'text truncation'
Group 151.png (667×820 px, 94 KB)
For both examples only one solution is shown, to see other examples go to the figma file 1) The title of each article is not truncate, the text is stacked, a 3 column layout is now a 2 column layout and the image is not present. 2) stack label over language
Group 154.png (697×830 px, 71 KB)
Long wordsLong words spilling over to the next line
Group 146.png (667×814 px, 84 KB)
A hyphen is added to words that spill over to the next line
Group 145.png (667×820 px, 82 KB)
Hyphen added
Solution - add hyphen.png (667×785 px, 57 KB)
GlyphsSome glyphs are the wrong size
Group 154.png (746×825 px, 107 KB)
Increase the size of meaningful glyphs as font size increases. When you use SF Symbols, you get glyphs that scale automatically with Dynamic Type size changes
Group 64.png (667×1 px, 170 KB)
Increase the size of icons to 31-32 px. If not possible then the icons need to be seen with the large content viewer
Group 144.png (667×799 px, 60 KB)
Text inside search barsThe text inside the search bars overflows the field
Group 140.png (667×375 px, 60 KB)
Make the type smaller
IMG_3769.png (667×375 px, 79 KB)
Change all to max. size 27 px.
Group 141.png (294×1 px, 22 KB)
Very large type sizeType is too large and doesn't follow the HIGs type size recommendations
Group 140.png (667×807 px, 257 KB)
With the default title size of 27, the largest type size should be around 62 pixels according to the table in ‘Large Accessibility Type Sizes’ in HIG. Use the table in HIG to check whether the type scales are appropriate
Group 68.png (667×800 px, 85 KB)
Articles: Below are the type sizes for AX5 Large accessibility text according to the table in HIG. Numbers: The size of the numbers inside the ovals was decreased. I use the SF symbols (size 31 px) or use font size 20 with a circle (instead of the oval) of 31px in diameter.
Group 140.png (667×901 px, 219 KB)
Issues with layout & paddingDifficulty seeing certain information due to fixed height of a section or inappropriate padding around the text
Group 138.png (667×1 px, 270 KB)
In the default size all of the information is accessible without scrolling. The padding around the words/buttons increases as the type increases.
Group 137.png (1×817 px, 149 KB)
For both examples only one solution is shown, to see other examples go to the figma file 1) For Wikipedia languages: Do not have scrollable sections and do not truncate languages, or headers of sections. Instead, stack the information. 2) For the picture of the day: Everything stays as it is, except the max typography size for the author's name is 28 px (so that it fits within the section and is not cut off).
Group 154.png (710×839 px, 184 KB)