Hey all,
I work in UX for a little company (Brass Nine Design) and joined the group
to chime in on this UX discussion:
Our library website is currently being redesigned to be responsive.
> The work is being done by an outside design firm and the project is
> being managed by University Relations, our school's PR department. The
> mobile version of our responsive site has several accordion menus
"Unfortunately, no, as this isn’t best practice. Accordions should
> require a click each to open and close; in other words, nothing on your
> page should move without a user action. This is true throughout our sites.
> See the universal Quick Links in mobile."
This is confusing because it's bad advice portrayed as "best practices."
Let's deconstruct it:
*Self-Closing Accordions*
At the most basic, a "self-closing" accordion is just a standard accordion.
Many UI frameworks will actually offer 2 rendering modes for tabs, one
where it's presented as tabs along the top or sides and the relevant pane
for a tab is displayed, another where it's rendered as a vertical or
horizontal accordion. In both of these constructs the other panes are
"self-closing." Forbidding that UI would mean forbidding tabs, which would
be especially strange given many sites' top navs are essentially a tabbed
interface.
So, forbidding the self-closing accordion is bad policy.
*Responsive Design in General*
It's also likely that whoever provided that advice is not thinking
Responsive. If you have your site built for 2 things, "mobile" and "not
mobile," you're not building a Responsive site. A Responsive site is one
that can handle:
- Today's devices - desktops, laptops, touch-laptops, tablets,
smartphones, and watches.
- Tomorrow's devices - likely smaller displays and larger displays,
higher DPI displays, and blind UI / voice-only.
The "tomorrow's devices" obviously requires a bit of forecasting but there
are things we know are coming, like the above higher DPI and need for
blind/driver's interfaces. Even today, users of the Apple Watch are going
to be happier talking through your site's resources than flipping through
it staring down at the little display on their wrist.
This leads to some technical requirements:
- No device should be assumed to be touch, mouse, or mouse-only. For
example many designers will add "Quick Links" to mobile figuring mobile is
touch and desktop/laptop is mouse. On mobile plodding fingers need to get
around the site more easily than a smaller, fiddly nav - but what about
Surface Pro users holding a high-DPI touch tablet, looking at the
desktop-render of your site - how are they going to deal with your fiddly
nav? You need to design and build it to interact well with both at all
sizes.
- No screen size can really be assumed, although there are a couple of
industry-standard minimums being established: Devices smaller than 640
physical pixels in width aren't in today's device mix, and smaller than 280
"virtual pixels" aren't either. "Virtual pixels" is the width Bootstrap
sees on a screen, the number of pixels available to font rendering if the
screen dpi were the historical standard of 72dpi. Usually the real dpi is
much higher - for example Apple's Retina phones will render at 96dpi,
144dpi, even 200dpi.
- Designers can't design for and devs build for a few discrete sizes,
like "desktop 1280" and "iPhone 320." The site needs to work at every
single pixel step from 280 on to infinity, or for now, 3200.
- The usual mechanics of building sites - don't use Flash, replace PDF
with HTML, deal with browser bugs in today's top devices.
- If you are going to be kind to blind users and build forward for
voice-only or voice-primary users like those driving, exercising or
interacting with a watch or Alexa or some future wearable, you should
follow Accessibility guidelines, and ARIA.
Accessibility guidelines are pretty old as the web goes and include placing
alt text on some images - any images that contain important information a
blind user would miss out on. And, avoid using CSS and JS tricks that would
hide important text from a screen reader. Following these also happens to
help your SEO score a little bit. Since the original question was about a
University site I should also warn that not doing this may be illegal, as there
are laws <http://webaim.org/articles/laws/usa/> in the US about government
and institutional websites and accessibility to the blind. The laws are
largely toothless as I've never heard of a web designer being cuffed and
lead away in shame (IN SHAME!) for designing an inaccessible site, but if
the conflict is budget vs blind users you might be able to use the law as a
cudgel in a conversation with management to get a win in for the blind.
ARIA is basically what someone earlier in this thread was wondering about -
how would a Screen Reader know a certain section of an accordion was open
or closed? The answer is you mark the panes that are closed as aria-hidden
and the control itself as role=tab:
http://accessibility.athena-ict.com/aria/examples/tabpanel2.shtml
http://www.webteacher.ws/2010/10/14/aria-roles-101/
http://www.w3.org/TR/wai-aria/roles#abstract_roles
|
