Forum Discussion
New in Storyline 360: Text Autofit Enhancements
Hi everyone,
We just released another update for Articulate 360, and thanks to your feedback, Text Autofit Improvements are no longer enabled by default.
This means, starting with this update, all new and existing projects that haven’t upgraded project text will remain with the legacy settings. If you have a project with text autofit enabled, you can update Storyline 360, then import the slides into a new project as they will not have the text autofit settings enabled.
Then, when you're ready, you can upgrade project text at any time to make the text more accessible to all learners. You can read more about this and all the new features and fixes below!
Hi Ren, a few months ago, you made this comment:
"Remove extra margin space in the text within shapes: Extra margin space can cause text to overflow the bounds of the shape. Remove that extra margin space by right-clicking on the shape and formatting the Text Box to remove unnecessary margins."
The extra margin space is a default that SL assigns to all text containers, so removing it is an added step for SL users. I can understand the need for a default text margin greater than zero for shapes and buttons, which default to visible boundaries. I don't advocate for making the default zero for those elements, but I'm not sure why a text margin greater than zero is necessary for text boxes, which have invisible boundaries. A margin causes text to be visually misaligned to other objects because the alignment is to the invisible boundary instead of the text itself. This forces SL users to take extra steps to remove unnecessary margins or live with imperfect alignment. I'd like to see Articulate make the default margins zero for new (invisible) text boxes.
I will note, however, that for objects with visible boundaries like shapes and buttons, the text margins are needed. The only way to avoid the scroll bars with accessible text, then, is to set autofit to Expand Height and use the margins to achieve the shape/button height and text centering that the user wants.
However, at the end of the day, there are still potential issues with accessible text and learners who need to zoom-in to read content. The crux of the problem is that Storyline slides have fixed dimensions and are fundamentally more akin to PowerPoint slides than web pages. When a user zooms in on a web page, it expands and adds vertical scroll bars to the entire page. A properly programmed web page rearranges the content to reflow at zoom levels up to 200% (WCAG's standard) so that horizontal scrolling is limited or non-existent, and vertical scrolling becomes necessary. By comparison, any attempt to expand the size of text and other content on a slide that does not, itself, expand or adjust accordingly will cause issues. I'm not saying that Storyline slides should become like web pages--if SL users want that, they should probably start using Rise (assuming it's fully accessible), which was designed for that kind of output. I'm just describing the limitation inherent in a tool that designs and outputs PowerPoint-like slides with fixed dimensions. I know Articulate feels strongly that accessible text is necessary for WCAG compliance, but in my opinion, this might not be achievable for Storyline output and, honestly, I'm not certain it's necessary for WCAG compliance when Storyline slides are intended to resemble PowerPoint slides and not web pages. An accessibility consultant would be best able to answer this.
In the meantime, SL users can strive to make their written content easier to read for low-vision users by ensuring font size aligns with the best practices for PowerPoint slides (e.g, depending on color contrast such as black text on white, many recommend 14 point or larger for bold text, or 18 points or larger for regular text). These are just a handful of sources on accessibility for PPT slides from Microsoft, HHS.gov, section508.gov.
Just my two cents, for what it's worth...
Thanks,
Lisa