Notes about Web Accessibility – Part 3

Status: Work in progress.
Last update: June 24, 2015

Lesson 3: Never rely only on color or images!

Web pages shall be designed so that all the information conveyed with color is also available without it.

Bad use of color examples:

  • Mark required fields on a form with red color.
  • Refers to a button only by it’s color “Click on the green button to continue”
  • Include text content on an image

How to use color on text elements:

The default contrast ratio of text and background has to be at least 5:1

Large scale text can allow a contrast ratio of at least 3:1 (18 point text or 14 point bold text is judged to be large enough to require a lower contrast ratio).

Incidental text, (text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content) or logotypes has no minimum contrast requirement.

Tools to check contrast ratio:

Lesson 3.1: Design and build web pages in a way that users can change the size of the text

  • Allow text to flow naturally at larger sizes.
  • Avoid defining text size in explicit units, like pixels or points, use relative values instead.
  • Again, don’t text inside of images. Use text!
  • You can add an “Adjust font size widget”.
  • Avoid moving, scrolling or flashing text. It could be extremely difficult to read.
Advertisements

Notes about Web Accessibility- Part 2

Status: Work in progress.
Last update: June 18, 2015

Lesson 2: Navigation

Rule: A method shall be provide that permits the user to skip repetitive navigation links. Specially when navigation is repeated in all pages or included in a page template.

User goal: Navigate to relevant content.

How?

  1. Include a links that allow the user to skip over the navigation and go straight to the main content in the page.
    These links can be visible or invisible for non-disable users.
    Example: “Jump to main content” or “Skip navigation”
  2. Use HTML Headings properly. Screen readers and some browsers allow users to move from heading to heading announcing the headings at the corresponding level (h1, h2, h3, h4, h5).

Some options of how to implement this:

  • Text link at the top (visible)
  • Text link positioned off the screen and move it in on focus
  • Use tiny image links (1x1px) of the same color of the background
  • Use text links of the same color of the background

Alert! Do not use display: none to hide navigation links. Screen readers respect display: none interpreting it to mean don’t display in any medium including speech.

TIPS: How to improve your navigation links (or any kind of links)

  1. Choose wording on your links so the user can understand what the link will do.
  2. Organize your content using true headings (h1, h2, h3, h4, h5) and lists.
  3. Make sure content is well structure and clearly written. Check spelling, grammar and readability.

UXDi at General Assembly. Project One: Sketching a mobile app

I’m currently student at the User Experience Design immersive program at General Assembly San Francisco. This is a full-time 10 weeks program to learn the basics and best practices of user experience design.

What I’m enjoying the most of the program is being with a group of people that is passion about design and so excited to learn that it’s impossible not to be engaged.

Time flies! We already completed 2 weeks in the program and we are already working on our second project. I’ll get to that later when it’s ready for sharing.

For my first project I worked on a mobile app that intends to reduce the food wasting at home by keeping track of the perishable food in your kitchen and their expiration dates. It also help users to discover delicious new recipes.

Story board

Image

After a couple of interviews with users and defining the problem I wanted to solved. I started creating user flows and sketching the main screens of the app.

User flow

Image

First sketches

IMG_1618

After some some drawings I was ready to build my first paper prototype. And I decided to make a video. Paper prototypes are fun to make. I think it’s a great resource, but it’s messy and it’s easy to lost track of changes. Anyway paper prototypes are very useful at the early stage of the design process to understand better the user flow.

Paper prototype video

After testing with paper prototypes, we moved to the screen using POP Prototyping on paper to create a tappable prototype. The biggest discovery on tappable prototypes it’s that even if you don’t test the app with any user, your sketches come to life and you can see the layout on the actual screen.

See my tappable prototype

POP paper prototype

We didn’t move forward with this project. But it was a great practice of user research and early stage prototyping. And the best part, it was really fun!

‘Labeling’, the worst enemy of makers

Moving from being a “business person” to become a “technology person” has been harsh. Specially because of prejudices we have about people and careers. If you think that business people don’t like technology or that marketing people can’t understand technology, let me tell you: you are wrong.

I studied Marketing and my whole career I have been working with technology, developing technology products, comparing technical specifications and analyzing marketing strategies for them.

Making the decision to learn how to code and start building by my own was really difficult. I remember when I started my first coding class and the instructor asked me why I was there. I was really shy and I felt I didn’t belong there. Coding was for engineers, so I replied nervously: “I’m here just to try to understand technology, I want to make a landing page, that’s it.” I used to feel I was not good enough or smart enough to become an developer.

I started learning how to code about a year ago. By this time last year I was having headaches trying to make a simple app with PHP and it seems like it was a very long time ago. I have learned a lot and I’m still a beginner, but I now know that I’m capable of building stuff. I know I’m not an engineer, but I’m a maker. So I’ll learn anything I need to make things happen.

Today, I still have doubts about what I will become at the end of this journey. Getting a job has been hard and I know finding the right position and the right company for me won’t be easy. But I’m happy and I’m learning new things everyday.

This is not the end of the story, I will continue searching for new challenges. But there are two things I have already learned in the past year and I want to share today.

The first one it’s that everyone can code. It doesn’t matter if you are a business person, a history major or an educator. Everyone can learn to code if they want to do it.

The second one, labels suck! I know it’s hard to stop labeling people by their career or education. But people shouldn’t discourage anyone to learn something new just because they are not from a technical career. So please stop doing it, specially to yourself. Throw away all the labels you have for yourself and go try something new.