Creating a More Inclusive Experience at Amex through Page Hierarchy and Component Reflow

In this blog post we will look at how a page hierarchy can affect accessibility, as well as why and when to reflow your components to create an inclusive experience. We will also showcase some of the reflow changes we made in the DLS accessibility release to support our accessibility efforts.

Pattern recognition is built into our DNA.

Pattern recognition has helped humans evolve into who we are today. Our brains take in large amounts of information and to help us process this information, we identify and store some of it as patterns. When this happens, we can recognize patterns much faster than having to recall information, reducing cognitive load. Patterns make things predictable. Not everyone sees a website, some people feel with braille readers or hear with Voiceover. The ability to rely on pattern predictability to navigate when you can’t see what’s next, is invaluable. For example, knowing that a header is at the beginning and footer is the end.

Assistive technologies rely on known components Aria widget Roles and a well-structured web page to help orient users. Heading tags (H tags) within HTML have a hierarchy from <h1> (H1) to <h6> (H6), which represent six levels of section headings. H1 is the highest section level and H6 is the lowest.

After leveraging H1 for the page title you can leverage the remaining heading tags to group content in a meaningful hierarchy. Think of these H tags as a way to organize your content into a meaningful outline. This would allow a user to leverage a keyboard to traverse the structure and allow a screen reader to announce each heading.

The H1 tag is the highest heading in HTML hierarchy. Within the DLS we provide text styles that also have a hierarchy. These styles can be associated to HTML H1-H6 markup. You will notice that our most prominent type of style is “Heading 6” which contrasts with H1 scale of HTML’s markup.

Avoid skipping headings in the hierarchy. For example, don’t use H1, H2 and then H4. This will confuse users using assistive technologies and potentially skip over vital information hierarchy that the user needs to fully understand and navigate the page content.

To learn more about how DLS V7 will address type hierarchy see our blog on Typography Scaled for an 8x Grid.

Content Reflow

Content reflow or responsive design helps define a layout that is more predictable for devices that leverage those screen sizes. Example being that there is less space on a mobile device than a desktop. Responsive design allows designers to have more control over the content for each device’s screen size.

• The reflow success criteria requires us to think about additional use cases. For instance, users with a vision impairment would need the ability to zoom into your website to interpret and leverage the UI. In this case, it is critical that every element within the UI reflows its contents appropriately.

• The WCAG site states that, “the success criterium around reflow is to help people with low vision who need to enlarge text and read it in a single column. When the browser zoom is used to scale content to 400%, it reflows - i.e., it is presented in one column so that scrolling in more than one direction is not necessary.

• For people with low vision, enlarged text with reflow enables reading. It is critical. Enlargement enables perception of characters. Reflow enables tracking. Tracking is following along lines of text, including getting from the end of one line to the beginning of the next line.

• Avoiding the need to scroll in the direction of reading to reveal lines that are cut off by the viewport is important, because such scrolling significantly increases the effort required to read. It is also important that content is not hidden off-screen. For example, zooming into a vertically scrolling page should not cause content to be hidden to one side.”

• Web Content Accessibility Guidelines (WCAG)– Success Criteria: Reflow

Viewing distance and display resolution

The value of 320 CSS pixels was chosen as a reasonable minimum size that authors can achieve. This value lines up with the reported viewport width of small displays of common mobile devices. The width of 320 CSS pixels exactly corresponds to a desktop browser window set to a width of 1280px and zoomed in to 400%. It should be noted that 400% applies to the dimension, not the area. It means four times the default width and four times the default height.

A letter of the same CSS pixel size on different displays with different resolutions - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

A letter of the same CSS pixel size on different displays with different resolutions - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

The following example from the BBC illustrates reflow in action. As the user zooms in the content reflows until it renders in a single column

DLS Components that now support reflow

Below are a few examples of how the DLS team has incorporated reflow into our components.

Breadcrumbs

This is a basic example where we had to address tap targets along with reflow from the accessibility audit.

Considerations

• How do we increase the breadcrumb height without affecting it visually?

• How do we ensure reflow of the content is accessible?

New – Accessible Breadcrumbs

• The breadcrumbs will now wrap when there isn’t enough width to fully display each item on one line.

• The overall height padding was increased so that the vertical tap target would be 44px.

Example Breadcrumbs Reflow

Date Range Picker

Accessibility Design Challenge

During the accessibility audit there were several issues identified around touch target sizes. As Harshal explains in, Increasing Target Size, we need to ensure that we have 44px touch targets. The calendar has a touch target for each day of the month which contributes to the overall width of the component. This introduced friction into our goal of reflowing at smaller breakpoints and zooming 400%.

Prior Version Considerations

• The overall width change has caused the calendar to be larger than our mobile grid. This was fine because the calendar would overlay.

• Could we remove the repetitive buttons within each date input?

• Could we leverage only 2 digits for year? No, we needed to be able to support a variety of date formats.

• Two calendars on the screen at one time.

Previous – Non-Accessible Version

New – Accessible Version

• Combined the Start and End dates to help consolidate space

• Single Calendar view reflects selections from either Start or End date input

• Consistent for small and large screens

• Increased overall tap targets to 44px

Tabs

Within desktop we will now support two lines of text for tabs. Tab titles will automatically reflow to two lines as horizontal space dictates.

Tabs – Desktop

Tabs – Mobile

Tabs are now vertical within the mobile breakpoint. The accessibility issue with the previous version was zooming a page would result in the loss of information.

There are many anti-patterns within digital design that have become mainstream which provides a false sense of growth and maturity in our industry. One of the benefits of being a designer is that we often see and evaluate things that others take for granted. We need to recognize these limiting anti-patterns so that we can provide the most accessible products. I believe our team has grown, become more mindful, and are able to provide accessible solutions.

If you have questions or comments, we would love to hear from you #dls-design

Reference

• [WCAG – Success Criteria: Reflow Page Structure] (https://www.w3.org/WAI/tutorials/page-structure/)