
Things Developers Should Do For Web Accessibility - laneshill
http://laneshill.me/2012/12/10-easy-things-all-web-developers-should-do-for-web-accessibility/
======
4lun
"Use alt tags where appropriate"

When you don't have need of an alt attribute, add one but keep it empty. In
the absence of an alt attribute some screen readers will read out the path of
the image instead. Setting it to empty allows you to remove this, almost
always, unnecessary noise.

------
protonfish
The mention of Fangs alone made this article valuable to me. Accessibility has
had lots of lip service for years but it is essentially impossible to do any
legitimate work optimizing for screen readers if you don't have access to them
(being prohibitively expensive.) It's like writing for a browser you never get
to test in. If anyone was serious about accessibility they should get simply
get screen readers in the hands of the people building web sites.

~~~
lesterbuck
NVDA is a free and open source screen reader:

<http://www.nvda-project.org/>

------
guycook
Number 1 (and throughout the article) isn't right, the input should go
_inside_ the label.

See <https://developer.mozilla.org/en-US/docs/HTML/Element/input> Permitted
content: None, this is a void element.

And <https://developer.mozilla.org/en-US/docs/HTML/Element/label> for an
example of doing it correctly

~~~
bphogan
It's completely legitimate to have an input tag outside of a label. Even the
link you provided states:

The HTML <label> Element represents a caption for an item in a user interface.
It can be associated with a control either by using the for attribute, or by
placing the control element inside the label element.

As long as you use the for attribute, it's fine.

~~~
guycook
Yes, quite right. I probably wasn't clear enough there, but I was referring to
this from the article:

    
    
      <input type="text" required><label>Social Security Number</label></input>
    

Should be marked up as

    
    
      <label>Social Security Number<input type="text" required /></label>
    

if you want to omit the 'for' attribute.

Doing it the wrong way around will still render as you expect, but defeats the
purpose as you won't get the click-to-activate behaviour.

~~~
bphogan
Ah yes, that's horribly, horribly wrong. :)

------
yuchi
Number 2 is simply misleading. It doesn't take in consideration HTML 5
Document Outline speification. It's not enough anymore to simply use h1-6
accordingly. You must take the whole document landing marks sructure in
account (`article`, `section` etcetera.)

Number 8 is not completely correct anymore. Javascript was recently included
in the accessible tecnologies. Screen readers nowadays do own a DOM and a full
rendering stack. ARIA, in fact, dictates a lot of interesting accessibility
states and tools. That said, I do not push forward the use of javascript for
structural functionalities, the rule that states that "Javascript is an
enhancement" still works and will always work, but excluding enhancements for
accessibility is naïve as far as the naïvete of the implementation.

~~~
gilrain
Not really misleading: most screen readers aren't yet using the HTML5 Document
Outline algorithm, so for accessibility you still have to rely on proper h1-6.

Ideally, you'd use them in combination for future proofing. It takes a little
work, but you can arrive at the same general outline from both algorithms,
since the new one ignores the ordinality of the h tag.

~~~
steveax
Screen readers will use whatever document outline that the browser renders,
no?

~~~
4lun
In my experience many screen reader users aren't on the latest version of
their accessibility software (cost and effort are among the reasons). So it's
not uncommon for users to be using screen reader software that doesn't account
for HTML5 elements.

------
stevejalim
0) Make sure all of your HTML is valid.

~~~
zalew
please. build for people, not validators. it's good to check for mistakes, but
validators are far from a stamp of approval for anything. know what you're
doing instead of seeking 'validated' crap.

~~~
saurik
People generally don't read HTML... machines do; the further levels of
validation you can obtain (and certainly to the extent to which the code is
somewhat valid at all, such as making certain to have tags that aren't
misusing quotation marks or brackets or entities), the more likely your code
is to be understood in the same way by random implementations of HTML parsing
that may be used in the field.

~~~
zalew
yeah, I remember injecting flash objects with javascript wrapped in cdata, so
the w3c validator confirms my awesome coding skills in green, good times. now
I treat validators as useful tools for double-checking syntax, and nothing
else. it validates more often than not anyway, but it's not that I care.

invalid code doesn't mean shitty code, and the other way around - being valid
doesn't say _anything_ about the practical quality of code. know your craft =
know the rules + know when you can break them.

------
jakub_g
Regarding JavaScript: some JS-heavy apps can be made accessible easier than it
looks at the first sight. One just needs to use <input> and <button> or <a>
for binding 'onclick' events, instead of <div>s, <span>s etc. [1] and perhaps
add some additional code to handle quirks in some browsers.

[1] [shameless self-promotion]
<http://jakub-g.github.com/accessibility/onclick/> \- comprehensive cross-
browser study of 'onclick' handling from JavaScript

