can anyone give me some tips or hook me up with some good links on this?
i'm having trouble finding much more than 'add alt text to the images' and i'm not sure how current the info is...
i get the whole semantic markup thing but could probably do with a bit more guidance on that too.
also not sure how things would work across different browsers.
1) Use HTML's heading tags for each and every section of content on your pages. The heading tags are: h1, h2, h3, h4, h5, h6
2) Ensure the prior mentioned heading tags exist with the proper heirarchal sequence. For instance h1 tags are important than h2 tags. Screen readers use these heading tags to navigate the content of the page. If they not present or improperly ordered a visually impared user cannot navigate the page's content.
3) Don't use JavaScript to dynamically change the content on the screen without first prompting the user that text will change. If JavaScript changes text on the screen before a screen reader can read the content there is no way a visually impared user can know that content was changed.
4) Don't serve the user a 1000 images. If an image does not convey relevant content then make it a CSS background image.
5) Be gracious with the title attribute, especially on anchor tags. This can tell the user where they are about to go.
6) Don't put text on an image that cannot be conveyed as alternate content. The visually impared do not read images.
7) Ensure all your meta data is relevant. If you change any of your content be sure not to forget the extra bits of descriptive data.
8) AJAX defeats accessibility. Be kind with your use of AJAX.
9) The visually impared, and actually almost all visual users, do not care how pretty your pages are. They are there to get information, shop, or what ever other specific purpose. Make your data easy to understand and quick to retrieve. If a user cannot get in, get what they wanted, and then get out in record time they won't ever come back.
10) Do not use any presentation tags or presentation attributes in your HTML. Use a stylesheet. If your HTML contains presentation conventions they are probably not accessibile.
11) If your content exists in a different order visually than how it is written in the HTML, from top to bottom, it likely fails accessibility. Keep things orderly and consistent. Users expect content to flow from top to bottom and for tab indexing to follow the flow of content.
12) Do usability testing with screen reader software. It is not possible to know how accessible a page is by looking at.
I am totally blind myself, and you'd be amazed how much stuff still doesn't have alt attributes on it after all these years... Be careful, there are still a lot of myths out there, such as no graphics allowed (wrong), talbes are bad (wrong) and frames are bad (wrong, though I realize frames are bad for other reasons.) Ideally you should have someone who is blind test your site, if you need further help on this feel free to email me at westbchris#gmail.com. One other thing, try to make controls that actually do things buttons and/or links. Clickable divs aren't cool because it is not obvious that they do anything, and depending on which assistive technology you are using you may not even be able to click on them.
Check out this explaination from Alertbox:
Disabled Users and the Web (The article is from 1996...but the issues still hold true, if not more so today)
...then follow the link at the bottom to the 148 page report with Design Guidlines (the document is copyrighted 2001 so it must've been updated since the original).
The term for this is Accessibility. Take a look at the W3C's WAI Website. I've always found Juicy Studio to be an invaluable resource for articles discussing accessibility.
There are in-depth definitions that are difficult to master and implement. Examples include Web Content Accessibility Guidelines (WCAG) and Section 508.
A less than official suggestion is to make your site easy to navigate with a text browser. Don't rely on colors or structure to convey content. Don't rely on widgets for important functionality.
EDIT: Thought I would add that you shouldn't bother testing your site with JAWS or another screen reader. Your inability to navigate a site would be more related to your inexperience with the screen reader rather than the inaccessibility of the site. That said, having a sample of your target audience test your site for usability is highly beneficial.
EDIT #2: As discussed in comments, I intended to convey that you shouldn't make judgements on a site's usability based on your experiences with a screen reader. That said, I would recommend that anyone in Web development have exposure to the browsers/equipment used to view web sites including screen readers. It was poor wording in the original edit.
Well, it looks like no one mentioned WAI-ARIA which is for the Accessible Rich Internet Applications. IE making things like gmail accessible. And a decent search term to find things like this a list apart article on wai-aria. Already pretty supported.
Related
We have inherited a website which we are currently trying to make WCAG2.0 AA compliant
One of the pages is failing the heading-order rule as it has an <h3> and <h4> tags but no prior <h1> or <h2>
We are in the process of adding an <h1> tag (as all pages should have one) but there is no need for an <h2> tag and to amend the <h3> and <h4> would involve a large refactoring of various jQuery code and CSS
Are there any tricks to make the page accessible? I'm loathed to put a hidden <h2> tag in as the screen readers would presumably pick this up. Or do they ignore the hidden tags and the page then becomes compliant?
Are you trying to satisfy WCAG 2.0 AA or are you trying to make the page accessible?
These are usually the same, but sometimes not.
A hidden <h2> would pass WCAG depending on how you hide it. That, however, would not make the page more accessible.
While this may suck, the best, most correct approach is to fix the <h3>s and <h4>s to become correct levels (that is my answer, the rest of this is fluff). Your question might be more appropriate if you instead provide some code samples and ask for tips on how to write a regex or otherwise script these replacements throughout the inherited system.
If you are being told you have no time to do it right, then code examples (or a sample site) might still be helpful to get some guidance.
I really have seen this situation before, and actually have fallen into this trap myself. By applying styles to the h3 and h4, it is possible to make a page look, well, a certain way.
Looking at the point of the header tags however, it is their purpose to add semantics to the document, as we all well know. Is it, therefore, meaningful to have a document outline where there is an h3 but no h2? Screenreaders and other accessibility tools use this header information and some could get confused.
My most influential decision-making point is, "how will the user consume this information?" Will they be able to consume it? Is it meaningful to skip a header level? I initially think not, but please let me know of your differing opinion!
If you really do care about accessibility, giving an empty h2 (even implicitly which is the case when you omit it) might give no clue, in some screen readers, of the announced section to users when they will navigate the outline of the document (1).
That being said, I can't find anywhere (neither WCAG or HTML5 documentation) where it's said that you can't omit one level of headings.
The only official (for HTML5.1) requirement is to use "headings of lower rank" to start new subsections, which should mean that you could use a h3 directly below a h1 but can't use another h1
Even the WCAG is giving an example using omitted ranks saying this example does not intend to prescribe the level for a particular section.
(1) HTML5.1 provides an outline algorithm where we can read about "implied headings" or about the use of the rank when there is an heading content element
I would say the best way to ensure compliance is to refactor the code that is in the javascript/CSS. To hide elements you could use the hidden attribute or aria-hidden.
https://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/
Sorry if this is a too naive question, but what exactly is a screen reader? How should I consider them when designing a web page (html document)?
Doing a google search doesn't help much... and wikipedia's entry is too general.
Is there anything I should be adding into my html markup to deal with screen readers in particular?
A screen reader is software that "reads" a document (in your case, a webpage) and outputs it in a way that people with visual disabilities (e.g. blindness) can easily consume.
A screen reader can only understand text (and some formatting). Here are things you can (and should) do to improve accessibility for blind or almost-blind people:
Use the <strong> and <em> tags rather than non-descriptive <b> or <i>. If it's being read aloud by the computer, it can put emphasis on those words.
Always include the alt attribute on images. You can even leave it blank (also known as null - alt=""); this signifies that the image is not essential/decorative. Otherwise, put a text description of the image.
The title attribute is generally ignored by accessibility software. In effect, only people that can use computer mouse can ever read it, so avoid it.
Turn of CSS and look at your page. If it doesn't make sense, you should reconsider the layout.
ARIA roles (via the role attribute) are helpful. For example, if you make a link look like a button, assistive technology provides different interactions. So by setting the role correctly, people using assistive technology can use that element as you intended. In that case you set role="button"
Use tags with semantic meaning (like section, article, nav, aside, header, as well as the more common h1...6 tags) rather than divs and spans that you style with CSS. This lets software make an outline of your page and a blind person can jump straight to the main content just like you can scan it with your eyes.
Related to the last one; make it a point to use lesser-known tags like time and abbr and address rather than yet another CSS class.
And that's just for screen readers. Not even considering deaf people -- look into captions for your videos and audio (with the new HTML5 <audio> and <video> tags).
Please be aware that I am not an expert on accessibility (and I'm not blind either, so I don't speak from experience). The W3C has standards on accessibility that are probably more advisable than mine (and a list of quick tips as well).
Screen readers are typically used to make the computers accessible to users with visual disabilities, e.g. If you are blind you won't be able to see a website but with software you can have it "read" to you.
The most common screen reader I know of is the JAWS screen reader.
JAWS is short forL J ob A ccess W ith S peech (hence the name) and is a common tool used when trying to ensure your website or Web application is accessible. E.g. Creating sites for the U.S. Government require ensuring your content is accessible according to the Section 508 of the Rehabilitation Act: http://www.section508.gov/
All of the info you might need is on that site but a few of the quick tips would be:
add informative descriptions to images with alt attributes
use <TH> tags to properly define table headers and use the scope attribute
ensure that your site/app still renders in a readable manner when the CSS is disabled
Your question is two folded:
A screen reader is a piece of software that reads the screen and converts that to something people with visual disabilities can consume, like audio or Braille. In terms of the web, it reads the DOM, versus the actual screen.
What you have to do can be quite simple: make your application easy to understand for screen readers. You do this for example by providing alt with an image. There is a standard for working with screen readers at the W3C called WCAG. What you really need to do primarily depends on your audience. If it is unlikely to have people with such disabilities on your site, you probably have to do none to less work for it.
When creating a website why should you care for HTML with no style?
Is there any device which will render HTML only (no CSS or JavaScript)?
Do you usually care how your website will display without CSS?
Why is it important?
There are several cases in which websites may be used without styling. As mentioned in the comments, screen readers (such as those used by visually-impaired people) read only content, not styling.
Perhaps more importantly, many search engine spiders (think: Google) read your site without styling. When you view your site without CSS, you will gain a better understanding of how search engines view your content.
And if you are lucky, or your content is particularly geeky, you may get the occasional guru who browses your site via Lynx.
There seem to be a few misconceptions here. First of all and most importantly, screenreaders do take into account CSS and JavaScript. Why? Simply because unlike in the past they are not running on their own, but rather work as addons for existing browsers or include the render engines inline in their own systems.
Does that mean you don't need to concern yourself with screenreaders at all? Sadly that's not the case either. For example, if you add display:table to an element just because you want to vertically align something some screenreaders will actually treat it like a real table (which makes no practical sense). The good part is though that pages are read top-to-bottom, header and menu first (if found) and that adding display:none through javascript to an element will hide the element from the screen reader as well. Now, the following is going to sound really harsh, but except if you're making a real high profile website I wouldn't advice you to concern yourself with this too much. On one hand screenreaders are becoming better and better (try for example the one that's included on your android device if you have a recent version of android) and on the other hand blind people are used to websites being a 'bit' messy. Now, that doesn't mean you should start using flash or otherwise crazy stuff, but it does mean that if you just write a proper website, make your menu a list, make your divisions divs and not tables etc. you should in general be fine. And if you are making a high profile website then you should check out WAI-ARIA.
Now, getting to the search engine part, that's not true either for the big search engines at least. Google does take styling into account. Not all the styling that's unimportant for Google, but it actually will realize which stuff is hidden and analyzes the javascript whether hidden content will be shown (as part of it's anti-SEO work), it will search for links in your javascript and probably lots more I am not aware of. Bing does this to a large extend as well, though for example duckduckgo does not do this too much/at all. Either way, once again, the notion that Google sees your site like lynx does was true in the far past, but by now is invalid.
And if you check your serverlogs you will see that nobody accessed your site through lynx. That's just the reality of life nowadays. In the past (again) people would occasionally use lynx if they only had access to a console, but nowadays it's far easier to pull your phone from your pocket which runs a full web browser.
First part of the answer : 'text based browsers'
Text-based browser list
Alynx
ELinks (active version of Links)
Emacs/W3
Line Mode Browser
Links
Lynx
Net-Tamer
w3m
WebbIE
Second part : 'search engines'
List of semantic search engines
List of search engines
Third part : 'web accessibility' where software helps people with disabilities get access to the web.
It's important to note that for the third part, accessibility, it is
sometimes a legal requirement. For example, in the UK it is illegal to
have a website that is not accessible to blind people. There are
similar requirements for US government services. – slebetman
It's also an applicable law in canada
See this list of tools from w3 for a Complete List of Web Accessibility Evaluation Tools
CSS isn’t an on/off thing. Although CSS may be completely disabled, it is much more common that some of your CSS settings get ignored or overridden. Here is an incomplete list of cases (see my CSS Caveats for some additional details):
Speech-based browsers generally ignore most of CSS, largely because most of CSS is directed towards visual rendering.
So do “text-only browsers” (more accurately, character cell browsers, which render in plain text only using a monospace font but may be able to use colors and bolding).
Search engines generally don’t care about CSS at all.
CSS support varies. The more advanced CSS features you use, the more probable it is that many browsers don’t implement them.
CSS support may be disabled by the user, completely or partially.
User style sheets may interfere with your CSS code or even override them.
Browser settings e.g. on minimum font size may make some of you CSS settings ineffective.
Browsers have bugs. The more complicated CSS techniques you use, the more probable it is that you trigger a bug in some browsers.
An external CSS file (the recommended way of using CSS) may get lost, e.g. a browser may need to wait (perhaps in vain) from a server, or an archiving system may archive an HTML file but fail to archive the CSS file.
Styling may get lost in transfer, e.g. when copying content from a web page to MS Word or Excel or Notepad or email.
I am using section tag for grouping topics and replies on the forum page. In cases that I need to load the topic and its replies on other article page, I use div tag for the same block and change topic title from h1 to h2. Although it is valid. But, for assistive technology, will this make navigating a bit confusing?
Assuming that the assistive technology you are talking about concerns mainly screenreaders, the best way for you to know how accessible your pages are is by downloading one yourself and testing it out. A free screenreader that I have used to do this is called NVDA but there are more out there.
In general, screenreaders work best when a page has a logical structure behind it. If you are displaying several articles, make sure that each article is located in a similar heirarchical location on the page and that each article itself resembles the others in terms of its structure. Using HTML5 semantic tags like article, aside and the like can be helpful but are not necessary. Screenreaders and other assistive technologies have made due for a lot longer than these tags have been around. They are certainly good to use when possible, but there are other more important ways to make your page accessible to as wide an audience as possible.
Another good thing to do is to use header tags for titles, and to use them in order. Screenreaders often give the option to users to skip from heading to heading in order to get a summary of what is on the page. You can also include visually invisible (via placing them far off the edge of the page using CSS) links at the top of the page, or in sections where placing a heading may not be appropriate visually. These will be read in context by screenreaders without your non-visually-impaired users seeing them.
If you are concerned about accessibility, a good way to get a clearer picture of how accessible your pages are is by following the WCAG (Web Content Accessibility Guidelines) standard recommendations. WCAG is managed by the W3C, and has various levels of accessibility that you can consider respecting when developing your content. The W3C has a list of validators that can be found here.
To answer your question from comments:
How it sound when read a topic title as h2, click it, then arrive the forum page and this topic title become h1?
This shouldn't confuse most people, especially if you do it consistently. I am assuming that you are making a news-like site.
Above Levi mentioned article tags. I would recommend using them if you are having multiple stories per page. The div tag is roughly the garbage can of the HTML world, you only should use it when nothing else is available. Article tags both give your code better syntaxical value as well as they have another feature, called a role. Roles allow a person using a screen reader to jump around a page, like they can with heading tags.
I keep making attempts at properly using HTML5 but I feel like it's still not even close to anything semantically valuable.
My attempts:
HTML5 Article node Architecture
HTML5 Blog Page Architecture
But there's such subtleties in every single tag!
My question is, what specific software out there on the web is actually doing things like processing our HTML DOM, calculating and comparing elements to say "oh, this is a <header>, and it's just after <section>, and it has <time> in it, so the <time> tag must be "metadata" in relation to the <header>...", and saying "The content within the <time> tag not only is the "published time", but also relates to the author's birthday, so it must be a special post (say because there was also a <cite> or <address class='vcard'> tag in there too)".
I mean, what benefit am I ever going to get in using HTML5 if I don't know the algorithms that are interpreting it? If I just stuck with the basic div, ol, ul, li, p, a, h[1-6] tags, I could do everything with half the number of DOM elements.
Looking forward to some specific algorithms that I can use to shape how I structure the DOM from here on out.
I'm at the point where I don't even think we should be using HTML5 tags at all. For example, on the iPhone especially, the goal should be to minimize dom elements to decrease load time. Plus, if the iPhone site is a mirror of the traditional browser version, the search engines won't even see the iPhone site (ideally). So there's no real point in making the DOM semantic. So if I can use 1/2 the amount of <div> tags to achieve the same layout as if I used a somewhat "semantic HTML5" rendition, and that's a good thing for the iPhone, why don't I do that for the regular browser too? That's where I'm coming from.
Articles like this are basically saying it's pointless to worry about semantic HTML.
What algorithms are reading your semantic HTML? Google, that's who. Their algorithm tries to extract every bit of meaning from pages that it can, because that helps Google construct smart, relevant search results. For one example, Google tries to determine the dates of things by reading the HTML and gives headers extra consideration in determining the overall topic of a page.
Also, your assertion that we shouldn't use HTML5 tags on the iPhone "to minimize dom elements" isn't founded in any technical basis. HTML5 doesn't dictate that we use more DOM elements, and in fact it can let us leave out tags that would be required by XHTML. You should use HTML5 on the iPhone more than anywhere else. For example, the new input types like number and email don't do much on the desktop, but that extra information can really make things nicer on the iPhone by allowing it to present an appropriate interface.
Whenever a "machine" tries to make sense of your content.
In addition to search engines (→ SEO), screen readers (→ Accessibility) interpret the markup. They get better from version to version.
Also, think of all the tools that might come one day. The great thing about the Web is, that all the web pages could still exist in 5, 10, 100 … years from now. Imagine the user-agents and algorithms and search tools that might exist then, and how they could extract the meaning of your old documents.
Search engines can/will better interpret your pages which combined with other factors will result in better rankings for your pages.
Moreover if you use the tags consistently and semantically, you could build your own reusable widgets and libraries that derive knowledge from the HTML structure independent of how the data is stored in the backend.
Consider this sample Google search where you can filter results by date. By using semantic HTML, for let's say, <article> and <time>, you can write a simple crawler that recreates this functionality or allows users to specify a timespan within which to search articles in your own site(s).
Off the top of my head, I don’t know of any algorithms making use of the new semantic tags in HTML5. (Obviously, that doesn’t mean there aren’t any.)
But the idea that you should tailor your HTML to specific algorithms is, I think, a bit contrary to how the web works. The web is worldwide, and will hopefully be around for a long time. We can’t know what uses our HTML will be put to, and useful algorithms can’t be written until there’s a good amount of actual content out there.
The <a> tag wasn’t designed with Google’s PageRank algorithm in mind. Some people thought links would be useless if they weren’t inherently two-way, because you’d get too many broken links when one end went away.
Of course, if the vague possibility of undefined future benefits makes it not worth using some or all HTML5 tags for whatever project you’re working on, don’t use them.
For me, the benefit of using them is that there’s a well-known, public, non-proprietary specification that tells you, and anyone else working on the code, what we’ve agreed the tags mean. Future developers don’t just get a <div> with a class name that I made up in a coffee-fuelled 7 p.m. code print, they get a tag designed and documented by people smarter and more experienced than me. There’s also the chance that the code will become more useful in future if people use the meaning contained in HTML5 tags in algorithms, whereas there’s less chance of that if it’s all just a bunch of <div>s.
I don’t think the size increase of our pages from HTML5 tags is particularly worth worrying about though. After gzipping, the size increases aren’t enough to worry about, especially as mobile performance is as much hampered by the latency (which you can’t do much about) as the bandwidth. Plus mobile bandwidth is likely to trend up, rather than down.