Overview

• Implement responsive/mobile design

• Unify desktop and mobile

• Overall layout / findability

• Vertical vs. horizontal panel scroll/swipe

• Left side / right side (desktop)

• Flexibilty? (integrators may choose a layout?)

• Previously discussed adjuster redesign based on user feedback

• Consistency of adjusters (check boxes vs on/off)

• Accessibility of sliders

• Naming/language

• Note: no GPII integration at this time

• Style - total redesign?

Meeting Notes

Mockups

Tab order expectation

• Would be better to keep the “show preferences” tab on top of the panel area

• Then focus moves from tab to first panel as expected (this is clearer in the vertical panel, where the tab stays on top)

• In current design, focus moves from “show display prefs” tab to page content

• Not good practice to push focus into panel / doesn’t follow panel structure/order

• How to best design for horizontal layout in desktop in this way?

• Open from the left?

Mobile

Vertical vs horizontal

• • Prefer horizontal layout

  • Vertical breadcrumb throws balance off

  • Might expect down arrow to  open more of the panel (i.e. to increase panel size)

  • Up arrow looks like it could collapse the panel

  • Previously had vertical panel scrolling in mobile in order to avoid interefering with contrast scrolling

• How to take up less screen real estate in mobile?

• Currently the header bar at the top takes up too much space

• Also when user is in reader mode - will remove everything outside the content including UIO

• Preferences may not apply to reader mode

• Touch the screen anywhere - opens menu - accessibility?

• Have it at top of page only?

• Blend into page menu?

• For ease of implementation - consistency between mobile and desktop - i.e.  vertical vs horizontal

ON/OFF toggle

• Keyboard interaction? enter/space toggles state

• Arrow keys? Would need to focus on each state separately - Probably not best

• Touch/mouse interaction?

• Touch/click specific state to change state, i.e. must touch or click ON to turn on (not just anywhere on the toggle itself, like in iOS)

• Toggles are built as check boxes (so screen-reader experience is that of a check box)

• New ARIA spec may include a switch label - Lisa will look into it

• Consider the appearance of the focus state and how this might look too similar to current state button/box/border - don’t want to confuse the two

Emphasis preference

• Replaced 2 check boxes (1. Links 2. Other inputs (buttons etc)) with one ON/OFF toggle

• ON/OFF toggle used for consistency

• If we want to keep links and other inputs separate, we could have 2 panels

• Note that when we integrate with GPII, we will likely need more granularity - this will apply to multiple preferences

• What do we want this preference to affect? Consider wording of “other inputs” - are there other inputs that it affects?