have you tried to navigate your site with only keyboard?
could you perform every action on that site? (everyone put there hand down)
did the tab order make sense?
did you always see the element in focus?
“full stack” devs seems to have forgotten some of the fundamentals of the web
paragraphs, headings are terminal block elements: they can’t contain other block elements
accessibility: enables hearing impaired, vision impaired, motor impaired users and more to access the web.
accessibility: allows your users to use their input device of choice. More than keyboards, mouses and screen-readers
WAI ARIA: Web accessibility initiative, accessible rich internet applications
We can use roles and states to describe the elements to assistive technologies
Screen readers require notification when content changes within the document using aria-live
aria-live can be used for anything is intended to be used for important information: error alerts, resorting tables
aria-live has three values: off, polite and assertive
off: will wait until the screen reader loops over the content
polite: will notify the user after the current action finishes
assertive: is poorly supported but in theory will interupt the current action
role=alert is used to tell a user of really important
Two main modes screen readers use:
read mode, standard mode can navigate the page
forms mode, can interact with form elements… but there is a catch… content that is not directly related to the form (eg p tags with alert messages) will not be read-aloud.
Form control error messages can be inaccessible, if it is not programatically related to the field (again, in a p-tag)
we can not use colour alone to define a form field is invalid
the error message needs to be programatically linked to the form
including the error message inside the label is a simple method of associating
when submitting forms, if an error occurs the user should be focused to the top of the form where there will be a description of the form
A good wrapper for errors prepares the page for the error while keeping them invisible to users
models have problems
keyboard users can tab outside the model, the model is active and it can be confusing
screen readers may not be notified of the model
screen readers may not be made aware of the purpose of the model
closing the model may move the user away from the locations in which they navigated to the model
fixing models
hide the model from assistive technologies, once they open hide the pages remaining content
set focus to the model itself, not content within the model
limit the tab key to the model for keyboard navigation
explain to the user what each element will do when they close a model, submit a form in the model, etc.
make a smart decision about where to position the user once the model closees
Models are shit but we can make them less shit
in page tabs
relationship between tabs and each panels content may not be clear
keyboard only navigation may not work on tabs
tab and arrow navigation (arrow to choose tab to display) is preferred
define the tabs as role=tabpanel, links as role=tab
define tab as aria-selelected=true/false, panel as aria-hidden
there is a lot to do around accessibility, but there are quick wins available to make the application accessible.
don’t be overwhelmed
this to do
test with keyboard only
test with one or more screen-readers
test screen-readers in different browsers, different bugs appear in diff browsers
get specialists in to help you
the ideal time to focus on accessibility is when you’re building the individual components, when you’re building pattern libraries.
It’s often said users are the weakest link in the security chain
How true is this, who are *we* designing for?
Human factors influence security
Passwords are broken, each accounts requires a human remembers
username
password
was the password reset recently
what are the rules are the password
For things for an account is easy to remember
Each email is associated with, on average, 130 accounts.
These four things are not easy to remember, 130 times.
Users make it easy to remember
This makes it easy for users to hack accounts.
Hackers will cycle email addresses against common passwords (this also gets around lock-outs from excessive attempts)
Two factor auth improves security for user, smart-phones make it 2FA easier than other physical tokens
Security needs to be easier to deal with but not too easy
SSL locks (or triangles or warnings) are not helping, users have tunnel vision and block the URL bar from the page.
The security information should be timely, clear and relevant
Chrome 36 and back had a timely and relevant SSL certificate warning that 63% of users would ignore and proceed to the untrusted sites, against the advice.
Chrome’s team decided they needed to redesign the page, hide the option to proceed to the warning page
The redesigned warning page reduced the number of people proceeding to 37%.
The redesign made the secure course of action clear.
11% of people click through to 419 scams, they don’t know what they don’t know
People don’t look for what they are not expecting.
Some FT users fell for a phishing attempt
The IT dept sent a link to users requesting they reset passwords.
The emails were seen by the phishers, who sent their own version.
The FT now uses 2FA globally. Savvy users fall for phishing too.
Phishing can include paper, urgent invoices.
Warnings aren’t a great help, people don’t notice the absence of warning.
Lunch with the fine folk at @canva, thanks for having me down @web_goddess
Kogan.com are going through a responsive web design.
Version three of their site (K3) has been around for ten years.
Kogan had a really good, really light weight m-dot.
The devs hated developing in two code bases
Wanted:
Feature parity
Responsive design
Speeeeeeeed
They started with the aim of a complete refresh.
It became apparent that a full refresh was not the right approach
After throwing out the full refresh, they took a step back and considered their site.
The new approach: responsive, keep it working
Coding is like Jenga: you change one thing a completley different Jenga tower collapses.
Started small, bring in people once it gets big enough that they’ll notice
On a narrow screen, you couldn’t see the add to cart button. <- important!
Add code to be deleted once the site is switched to responsive (add a min-width and max-width, remove min-width later)
Pick random breakpoints, they will change as the site develops.
Add a test mode while working on the css but before the site goes responsive.
Just because someone on the net says something is a hack doesn’t mean you shouldn’t use it. Floats Vs Flex-box for layout. Everyone on a team knows how the floats works
CSS is a hack
Don’t make an overriding class, you’ll just need to add be twice as specific as you want to change things, eg body.k4
Avoid nesting, use classes.
Put Sass variables in the same file in which you use them.
Know when to steal, eg steal @snookca’s accessible visibility code.
In the early dev stage, don’t worry about poor performing selectors. Fix them later, they’re more performant than the 5 meg of ads on every page!
Hide code, make it hard to change CSS file that are only intended to be deleted from.
Use component media queries, nest the media queries within the component.
Choose a naming convention, it doesn’t matter which one.
Needed to build a theme for a new brand, we needed to change colours.
Turns out $red was not a great variable name
Went a themify mixin
m-dot site was turned off a few weeks ago, no change to conversions.
Fairfax have learnt a lot about iterative design since starting the redesign of their site
Responsive redesign of SMH is a massive project with many contributors: designers, developers, engineers, everyone at fairfax.
SMH was founded in 1931, committed to honest accountable journalism
SMH went online in 1995, a trial blazer of getting online in the news world.
Before getting too excited, it did look a bit shit (my words, not theirs).
For many people smh.com.au is the SMH, the paper may not be picked up
The site is made up of partner sites, video, etc
The site is used on a number of devices, mobiles on public transport, tablets in the evening
Fairfax wanted to people to be able to reach the content regardless of devices
They put together a dream team to work on the RWD site.
For the new site, they needed designers to be able to design an element and put it in the CMS. Not currently possible
There were five defining mantras they referred back to often, even now.
Fairfax wanted to move away from multiple dev streams: m-dot, desktop, etc to a single dev stream: rwd.
SMH went with an adaptive layout
SMH had fallen behind the a-game. Ganiad already had a RWD site.
Mobile geddon had arrived. SMH did not have a “tablet” site.
SMH’s RWD team take performance very seriously, faster, faster, faster.
They made hard calls about what was in and out. No way to redesign entire site in 18 months, too complex.
they new they needed to change their process: iterative design over waterfall
Mandates:
No wireframes (initially), 60 minute design sessions to get a live prototype
Quick’n’dirty: quality kept with design principles, style guides.
Screen agnostics: impacted the design approach by going tablet first after a false start. Tablet is where RWD lives or dies.
Lean user testing: less users more often.
Sharing is caring: content (article) is the new home page, people visit news sites via social media
Decide with data: testing gets feedback, beta site allows further testing.
They gave the project the code name project lego. Building blocks not pages.
Using building blocks, they can build and trial a site quickly
Using A/B testing to discover the difference between what people wanted and what people thought they wanted.
At Fairfax they are still learning about RWD,
never test on yourself, test on the user
don’t hide what you are doing
rules will change, design for today
Features will always be improving, this is not a design that will finish.