4 ms·

Things Developers Should Do For Web Accessibility

110 points by laneshill 14y ago

yuchi 14y ago
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 14y ago
  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 14y ago
    Screen readers will use whatever document outline that the browser renders, no?
    - 4lun 14y ago
      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 14y ago
0) Make sure all of your HTML is valid.
- zalew 14y ago
  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.
  - stevejalim 14y ago
    Well, yes (build for people) and no (stuff should be technically correct, as well). For instance, the WGAC 2.0 guidelines require that HTML be valid, and if a client wants WGAC 2.0 compliance (even A level, not AA), the site's gotta validate [1]. [1] http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-pars...
    - zalew 14y ago
      unless you are doing it for bureaucracy's sake (public sector, etc.), do what works, not what some ink on paper from half a decade ago says, otherwise it's CYAE[1]. http://www.alistapart.com/articles/tohellwithwcag2 http://www.alistapart.com/articles/tohellwithwcag2 "To Hell with WCAG 2" (2006) [1] cover your ass engineering
      - DanBC 14y ago
        > do what works Too many people build something that works for them; on their browser version, at their screen size, on their OS. That's especially harmful for accessible sites.
  - saurik 14y ago
    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.
guycook 14y ago
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 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 https://developer.mozilla.org/en-US/docs/HTML/Element/label for an example of doing it correctly
- bphogan 14y ago
  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 14y ago
    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 14y ago
      Ah yes, that's horribly, horribly wrong. :)
4lun 14y ago
"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 14y ago
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 14y ago
  NVDA is a free and open source screen reader: http://www.nvda-project.org/ http://www.nvda-project.org/
jakub_g 14y ago
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/ http://jakub-g.github.com/accessibility/onclick/ - comprehensive cross-browser study of 'onclick' handling from JavaScript

110 points by laneshill 14y ago

yuchi 14y ago

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 14y ago
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 14y ago
  Screen readers will use whatever document outline that the browser renders, no?
  - 4lun 14y ago
    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 14y ago

0) Make sure all of your HTML is valid.

zalew 14y ago
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.
- stevejalim 14y ago
  Well, yes (build for people) and no (stuff should be technically correct, as well). For instance, the WGAC 2.0 guidelines require that HTML be valid, and if a client wants WGAC 2.0 compliance (even A level, not AA), the site's gotta validate [1]. [1] http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-pars...
  - zalew 14y ago
    unless you are doing it for bureaucracy's sake (public sector, etc.), do what works, not what some ink on paper from half a decade ago says, otherwise it's CYAE[1]. http://www.alistapart.com/articles/tohellwithwcag2 http://www.alistapart.com/articles/tohellwithwcag2 "To Hell with WCAG 2" (2006) [1] cover your ass engineering
    - DanBC 14y ago
      > do what works Too many people build something that works for them; on their browser version, at their screen size, on their OS. That's especially harmful for accessible sites.
- saurik 14y ago
  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.

guycook 14y ago

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 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 https://developer.mozilla.org/en-US/docs/HTML/Element/label for an example of doing it correctly

bphogan 14y ago
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 14y ago
  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 14y ago
    Ah yes, that's horribly, horribly wrong. :)

4lun 14y ago

"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 14y ago

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 14y ago
NVDA is a free and open source screen reader: http://www.nvda-project.org/ http://www.nvda-project.org/

jakub_g 14y ago

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/ http://jakub-g.github.com/accessibility/onclick/ - comprehensive cross-browser study of 'onclick' handling from JavaScript