Things Developers Should Do For Web Accessibility
1–10 of 23 posts
Re: Things Developers Should Do For Web Accessibility
#2Number 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.
Re: Things Developers Should Do For Web Accessibility
#30) Make sure all of your HTML is valid.
Re: Things Developers Should Do For Web Accessibility
#40) Make sure all of your HTML is valid.
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.
Re: Things Developers Should Do For Web Accessibility
#50) Make sure all of your HTML is valid.
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.
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...
Re: Things Developers Should Do For Web Accessibility
#60) Make sure all of your HTML is valid.
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.
Re: Things Developers Should Do For Web Accessibility
#7Number 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.
Re: Things Developers Should Do For Web Accessibility
#80) Make sure all of your HTML is valid.
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.
Here's the thing: It's not uncommon to come across weird bugs/rendering errors on web pages that were caused by incorrect HTML (where the developer writes where he should have written and similar issues). Pages with those kind of errors might render fine in Browser X and yet have render errors in Browser Y. That's why you validate - to find those kind of bugs.
Re: Things Developers Should Do For Web Accessibility
#90) Make sure all of your HTML is valid.
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.
Unfortunately on the topic of accessibility you're likely going to need to design for people, but build your site to validate. I don't have much experience using screen readers, but from what I can tell they're going to need at minimum well build HTML.
Re: Things Developers Should Do For Web Accessibility
#10Earlier 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.
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