Skip to content

Commit

Permalink
#11: preparação, reidentação manual, prefere uma frase por linha em v…
Browse files Browse the repository at this point in the history 
…ez de 80 caracteres forçado
  • Loading branch information
@fititnt
fititnt committed Oct 4, 2016
1 parent 10f5c23 commit 883386f
Showing 1 changed file with 88 additions and 107 deletions.
195 changes: 88 additions & 107 deletions especialista/alison-walden/wireframes-acessiveis-em-5-passos/index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -27,10 +27,9 @@ isDraft: true
isReleaseCandidate: false
---

Most websites in North America and Europe now need to meet accessibility
requirements. These include requirements described by Section 508 of the
American Disabilities Act (ADA). They also refer to the Web Content
Accessibility Guidelines (WCAG 2.0).
Most websites in North America and Europe now need to meet accessibility requirements.
These include requirements described by Section 508 of the American Disabilities Act (ADA).
They also refer to the Web Content Accessibility Guidelines (WCAG 2.0).

Follow these five easy steps to make your wireframes more accessible:

Expand All @@ -43,18 +42,17 @@ Follow these five easy steps to make your wireframes more accessible:
One: Document the heading structure
-----------------------------------

Remember the last time you wrote an essay? You probably had a series of sections
in your essay that each had a heading. Most likely you had a table of contents
that listed all your headings. If someone read your table of contents, they
would have had a good idea of what your essay was about.
Remember the last time you wrote an essay? You probably had a series of sections in your essay that each had a heading.
Most likely you had a table of contents that listed all your headings.
If someone read your table of contents, they would have had a good idea of what your essay was about.

This is what headings are for on a website. They should describe the page they
are on. Assistive devices like screen readers allow users to navigate web pages
by headings. This is one way that a non-sighted person can "scan" a webpage, by
choosing to hear all the headings on the page. Listening to the headings allows
them to assess if the page is useful for them. If the headings are not developed
and written in a clear and proper way, they will not be helpful to this
audience.
This is what headings are for on a website.
They should describe the page they are on.
Assistive devices like screen readers allow users to navigate web pages by headings.
This is one way that a non-sighted person can "scan" a webpage, by choosing to hear all the headings on the page.
Listening to the headings allows them to assess if the page is useful for them.
If the headings are not developed and written in a clear and proper way,
they will not be helpful to this audience.

<!--
N.T: O trexo abaixo é o HTML original. Vamos manter esse comentário até que
Expand All @@ -67,91 +65,80 @@ audience.

![A primary heading that asks the question, Should I be a primary heading?](media/headings.jpg)

The experience designer or copywriter should decide the heading structure. The
wireframe or content matrix should include an annotation that describes the
heading structure. A developer should not decide the heading structure by
herself (in absence of documentation).
The experience designer or copywriter should decide the heading structure.
The wireframe or content matrix should include an annotation that describes the heading structure.
A developer should not decide the heading structure by herself (in absence of documentation).

Two: Document hidden way-finding cues
-------------------------------------

Screen reader users benefit from additional way-finding cues to help them
navigate a webpage. These include:

- "Bypass block links": These allow screen reader users to skip over repeated
blocks of content.  Without them, screen reader users would have to tab
through repetitive blocks of content from page to page. They are most often
used to skip over navigation menus. Other candidates for bypassing include
filter menus or carousels with many panels.
- Bypass block links can be hidden by default, but should appear on
keyboard focus. They should allow the user to skip past the content block to
the content immediately after. It's important to test these with your
keyboard once they are implemented. Make sure that you can tab once into the
content area, and tab again into the next interactive element in the
content area.
Screen reader users benefit from additional way-finding cues to help them navigate a webpage.
These include:

- "Bypass block links": These allow screen reader users to skip over repeated blocks of content.
Without them, screen reader users would have to tab through repetitive blocks of content from page to page.
They are most often used to skip over navigation menus.
Other candidates for bypassing include filter menus or carousels with many panels.
- Bypass block links can be hidden by default, but should appear on keyboard focus.
They should allow the user to skip past the content block to the content immediately after.
It's important to test these with your keyboard once they are implemented.
Make sure that you can tab once into the content area,
and tab again into the next interactive element in the content area.

Three: Document focus order information and specify the visible focus state
---------------------------------------------------------------------------

### Focus order

Focus order is an important concept for keyboard accessibility. It refers to the
order that elements on the page receive keyboard focus. The usual focus order
for the Western world is from top to bottom, left to right, the same way we
read.
Focus order is an important concept for keyboard accessibility.
It refers to the order that elements on the page receive keyboard focus.
The usual focus order for the Western world is from top to bottom, left to right, the same way we read.

For keyboard users, a common way to access a website is to move through the
content by pressing the tab key. The tab key moves the focus state to links or
form elements. Screen reader users can have their device begin reading the page
at any point.
For keyboard users, a common way to access a website is to move through the content by pressing the tab key.
The tab key moves the focus state to links or form elements.
Screen reader users can have their device begin reading the page at any point.

Usually experiences benefit from implementing a default focus order. There are
instances where the focus order should be changed. This is best determined by an
experience designer.
Usually experiences benefit from implementing a default focus order.
There are instances where the focus order should be changed.
This is best determined by an experience designer.

The following flow illustrates a situation where the default tabbing order
should be overridden:
The following flow illustrates a situation where the default tabbing order should be overridden:

- User clicks on a link to log in to a website, and the log in link leads to a
different page.
- By default, the first focused area on the page would probably be in the top
left-most link or form field. But in this instance, the user is definitely
there to log in. It makes sense here to put the focus state on the first
field in the sign in form.
- User clicks on a link to log in to a website, and the log in link leads to a different page.
- By default, the first focused area on the page would probably be in the top left-most link or form field.
But in this instance, the user is definitely there to log in.
It makes sense here to put the focus state on the first field in the sign in form.

Again, this cannot be decided by a developer in absence of documentation. It
must be annotated in the wireframe.
Again, this cannot be decided by a developer in absence of documentation.
It must be annotated in the wireframe.

### Visible focus state

The visible focus state is the visual indicator that an element has focus. It is
common for designers to create a hover state for mouse users. Usually the focus
state should match the hover state.
The visible focus state is the visual indicator that an element has focus.
It is common for designers to create a hover state for mouse users.
Usually the focus state should match the hover state.

For developers to handle this state in their implementations, it must be defined
in the wireframe. Additionally, the design of each element's focus state must be
described in the style guide. Each browser has its own default focus state.
Either allow this to be used, or have the designer create a new one that matches
your client's branding.
For developers to handle this state in their implementations, it must be defined in the wireframe.
Additionally, the design of each element's focus state must be described in the style guide.
Each browser has its own default focus state.
Either allow this to be used, or have the designer create a new one that matches your client's branding.

Many clients do not understand the value of the visible focus state. When it is
described in the style guide, the client has an opportunity to see it up front
and ask questions about it.
Many clients do not understand the value of the visible focus state.
When it is described in the style guide, the client has an opportunity to see it up front and ask questions about it.

> What is a visible focus state?
>
> Try it out on my website: Press your tab key now and try to see what the
> current focused element is on the site. You will see that my navigation links
> along the top of the site get underlines, and other links change color and
> have an outline. This is so keyboard users can see where the focus is.
> Try it out on my website: Press your tab key now and try to see what the current focused element is on the site.
> You will see that my navigation links along the top of the site get underlines,
> and other links change color and have an outline.
> This is so keyboard users can see where the focus is.
Four: Provide clear link labels
-------------------------------

For users who navigate with a screen reader, many of them will only hear link
labels. They will not have any context on surrounding information. That's why it
is important to make sure the link itself (or the form field label) is
meaningful.
For users who navigate with a screen reader, many of them will only hear link labels.
They will not have any context on surrounding information.
That's why it is important to make sure the link itself (or the form field label) is meaningful.

Do this: Learn more about our services

Expand All @@ -162,38 +149,35 @@ Do this: Edit my account settings
Don't do this: Edit

Sometimes the context is clear to a sighted user based on surrounding content.
In this case, indicate in the wireframe that the developer should hide the
additional content from sighted users. This way, a sighted user who can gain
context from the surrounding content will see "Learn more". A non-sighted user
will hear, "Learn more about our services".
In this case, indicate in the wireframe that the developer should hide the additional content from sighted users.
This way, a sighted user who can gain context from the surrounding content will see "Learn more".
A non-sighted user will hear, "Learn more about our services".

Five: Design simple, usable forms
---------------------------------

### Usable form design

I often ask designers if they plan to enter their form design into the coveted
Form Design Awards. Usually they stare back at me blankly. Sometimes they perk
up and ask for more information about these awards.
I often ask designers if they plan to enter their form design into the coveted Form Design Awards.
Usually they stare back at me blankly.
Sometimes they perk up and ask for more information about these awards.

There are no Form Design Awards. Isn't it great? We can put our aesthetic goals
aside and focus on making the form usable. Trust me: forms are meant to be
filled out. They don't need to be flashy. It's okay if they aren't ultra clean
and sleek.
There are no Form Design Awards. Isn't it great?
We can put our aesthetic goals aside and focus on making the form usable.
Trust me: forms are meant to be filled out. They don't need to be flashy.
It's okay if they aren't ultra clean and sleek.

Here are some form design best practices that also make the form more
accessible:
Here are some form design best practices that also make the form more accessible:

- Place the label above the form field, not beside it.
- Put a "required field" indicator inside the field's label. It's also helpful
to put "(optional)" within optional field's labels.
- Do not replace proper form fields with placeholder text. Users of all ages
and abilities complain about this. Placeholder text disappears when a user
clicks into the field and begins to type. It can be hard to remember what
content the field needed (e.g. Email address vs. username).
- If fields do not have a visible label (e.g. search fields), provide the
annotation for a hidden label. Indicate the label text. All form fields must
have labels.
- Put a "required field" indicator inside the field's label.
It's also helpful to put "(optional)" within optional field's labels.
- Do not replace proper form fields with placeholder text.
Users of all ages and abilities complain about this.
Placeholder text disappears when a user clicks into the field and begins to type.
It can be hard to remember what content the field needed (e.g. Email address vs. username).
- If fields do not have a visible label (e.g. search fields), provide the annotation for a hidden label.
Indicate the label text. All form fields must have labels.

![Form field labels should be placed above the field, not beside it.](media/label-top-of-field.jpg)

Expand All @@ -208,20 +192,17 @@ placeholders](https://www.nngroup.com/articles/form-design-placeholders/)*

### Accessible form error messaging

Screen readers automatically read out form field labels when the field has
focus. The form error messaging flow should work like this:
Screen readers automatically read out form field labels when the field has focus.
The form error messaging flow should work like this:

- User fills out a field the wrong way.
- User attempts to submit form.
- The first form field that has an error message should automatically gain
keyboard focus.
- The form field error message should be programmatically appended to the
field's label.
- The first form field that has an error message should automatically gain keyboard focus.
- The form field error message should be programmatically appended to the field's label.

In this way, the screen reader will read out the form field followed by the
error message text. Example: "Email address. Email address is a required field."
The user can then fix this issue, then tab through the rest of the form and hear
any other error messages along the way.
In this way, the screen reader will read out the form field followed by the error message text.
Example: "Email address. Email address is a required field."
The user can then fix this issue, then tab through the rest of the form and hear any other error messages along the way.

<!--
N.T: O trexo abaixo é o HTML original. Vamos manter esse comentário até que
Expand All @@ -244,5 +225,5 @@ You might be interested in these other articles related to accessible user exper
- [Usability should include
accessibility](http://accessib.li/2016/03/18/usability-should-include-accessibility/)

Let me know in the comments section what accessibility features you add to your
wireframes.
Let me know in [the comments section](http://accessib.li/2016/08/28/how-to-make-your-wireframes-more-accessible-in-five-easy-steps/#respond)
what accessibility features you add to your wireframes.

0 comments on commit 883386f

Please sign in to comment.