Things Developers Should Do For Web Accessibility

Post by zalew » Fri, Dec 28, 2012, 2:37 PM UTC

saurik wrote: post #6

zalew wrote: post #4

Earlier quoted context omitted.

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.

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.

Post by bphogan » Fri, Dec 28, 2012, 3:42 PM UTC

guycook wrote: post #12

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

Post by DanBC » Fri, Dec 28, 2012, 3:47 PM UTC

zalew wrote: post #10

stevejalim wrote: post #5

Earlier quoted context omitted.

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-pars...

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 "To Hell with WCAG 2" (2006) [1] cover your ass engineering

Post by bphogan » Fri, Dec 28, 2012, 4:54 PM UTC

guycook wrote: post #16

bphogan wrote: post #13

Earlier quoted context omitted.

It's completely legitimate to have an input tag outside of a label. Even the link you provided states: The HTML 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.

Yes, quite right. I probably wasn't clear enough there, but I was referring to this from the article: Social Security Number Should be marked up as Social Security Number 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.

Post by steveax » Fri, Dec 28, 2012, 5:54 PM UTC

gilrain wrote: post #7

yuchi wrote: post #2

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 render…

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.