I am working on doing accessibility remediation to several websites based off WCAG 2.0 AA standards. These sites have quite a lot of links to PDFs. Here is a common example of what they have:
Get Blah Information
Based on my best understanding of WCAG 2.0 AA principles, this links should have title text added, becoming something like:
Get Blah Information
My question is about this title text. It only seems occasionally appropriate. Most browsers will open the target="_blank" in a new tab, not a new window. Also, on mobile many devices will launch a native app to open the PDF. Some devices/browsers will actually download the file, depending on the settings. With all these considerations, is there a better, more universal title for these types of files?
It's generally considered courteous to give people a heads-up that that what they are clicking on will not open up as a webpage.
In my organization, we require that PDF links (or any link pointing to a non-HTML document) needs to clearly annotate the file type in the anchor text.
Like this:
Get Blah Information (PDF)
The title attribute isn't consistently supported among screen-reader/browser combinations, so I wouldn't recommend depending on it to work.
Links to Non-HTML Resources
https://webaim.org/techniques/hypertext/hypertext_links#non_html
Users should generally be alerted to links that lead to non-HTML resources, such as PDF files, Word files, PowerPoint files, and so on. However, there is some debate as to whether the content author or the browser should be the one to alert the user. The trouble is that none of the browsers or screen readers currently alert the user at all, so the debate is more theoretical than practical.
If you're opposed to putting the filetype in the anchor text, you could always use the aria-label attribute to supplement the anchor text, or position the text off screen so that it's not visible to sighted users, although these solutions may be less accessible for users with limited-sight ability.
I would avoid using the title attribute in this case. There are several issues with its use, and it should be avoided in most cases. For example, screen reader software will often read the title attribute in addition to the text that is already in the link, thus reading redundant and potentially confusing text. The way that the title attribute is handled is inconsistent across assistive technology. Read more about when to use and not use the title attribute.
Additionally, I would avoid describing the action that will take place. As you described, different technology/devices handle the link in different ways, and the user can even choose how to interact with the link (open in a new tab, etc). Instead, focus on describing the purpose of the link. Your first example: Get Blah Information is much better than the second.
Related
For the HTML title attribute, Mozilla's docs mention...
Use of the title attribute is highly problematic for:
People using touch-only devices
People navigating with keyboards
People navigating with assistive technology such as screen readers or magnifiers
People experiencing fine motor control impairment
People with cognitive concerns
This gives me a seed of doubt whether I can innocuously use title all over the place.
Would the mere existence of title actually introduce problems for certain users?
Or put another way, is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?
I'm just trying to maximize my UX & accessibility optimizations to 110%.
I can conceive of three different problems that using title attributes can introduce for those various groups.
No access
Some users don't use technology that would display the title attribute. This isn't a problem is the title attribute contains information that isn't required to understand the content.
Physically getting in the way
A tooltip might cover up some other information when it is rendered. You can probably compensate for this with space. Don't cram everything together. Allow enough room on a hover target so a tooltip can render in empty space, or at least space that doesn't contain information about the element being hovered.
Interruptions
If you scatter titles in the middle of a sentence, then I expect some screen readers will interrupt the sentence to read the tooltip. This won't make it easy to understand the document if it happens a lot.
I wouldn't go overboard with them.
(Related, but less of an accessibility issue, if the titles duplicate information in the text, then it is going to be very repetitive and annoying).
That depends, as always. Usage of the title attribute is not harmful, but relying on it is.
To quote the HTML standard:
Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).
https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute
Mostly, title is used to implement the tooltip pattern, which is then not very accessible, as stated.
So if you provide that supplemental information by accessible means as well, the title attribute does most likely not harm.
“[…] is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?”
Well, the WCAG accept title attributes as a sufficient technique to explain abbreviations in an <abbr> element or to label form controls, even though actual technical support is not great.
To name <iframe> elements it is still the only documented sufficient technique
If you use it on <style> and <link> elements, it allows the browser to provide a style switcher.
<link rel="stylesheet" href="dark.css" title="Dark Theme">
See also The Trials and Tribulations of the Title Attribute
Is there currently (2019/10, or in the HTML "living standard") a "standard" way to alert assistive tech users that audio content is available for a given article/page of text?
E.g., the opposite of a podcast transcript. Instead of providing text for audio, I am looking for a way to alert assistive tech that audio exists for a given text.
Is this a thing?
Note: I see that the WCAG Checklist states:
If the audio or video is designated as an alternative to web content (e.g., an audio or sign language version of a web page, for example), then the web content itself serves as the alternative.
And perhaps that is my answer? That providing an "audio" version of something implicitly links it to the text provided? Am I understanding that correctly?
If you are looking for a particular markup to signal alternate content, as far as I know there isn't something that specific.
So the passage of the spec that you have found says it all: the best and the simplest is to put a link in a sensible place.
Now, more deeply into the fundamental question, is an audio alternative for a text useful?, I would like to answer no in general.
As a blind or visually impaired, we all have assistive technologies that read the text for us, this is called screen reader.
We usually take time to configure a voice with its settings (speed, pitch, etc.) to our liking.
People having other handicaps, like dyslexia, also have assistive technologies of that sort.
There's also apps to read text on mobile outside of the browser, for example VoiceDream Reader on iOS, with the same possibilities to configure the voices to use.
Apps like VDR aren't exclusive to visually impaired, people who read books while driving can also use them.
Finally, it's quite improbable that your audio be used instead of our own ways to read text. It's becoming really useful only if there's added content compared to the raw text:
For example accompanying music, sound effects, and/or text played by an actor or at least read by an human...
If there isn't that added content compared to the raw text, then providing an audio just for the text is totally useless. If you are providing an audio version because the original text isn't accessible, then you'd better make the original text accessible first.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 months ago.
Improve this question
I have my blog (you can see it if you want, from my profile), and it's fresh, as well as google robots parsing results are.
The results were alarming to me. Apparently the most common 2 words on my site are "rss" and "feed", because I use text for links like "Comments RSS", "Post Feed", etc. These 2 words will be present in every post, while other words will be more rare.
Is there a way to make these links disappear from Google's parsing? I don't want technical links getting indexed. I only want content, titles, descriptions to get indexed. I am looking for something other than replacing this text with images.
I found some old discussions on Google, back from 2007 (I think in 3 years many things could have changed, hopefully this too)
This question is not about robots.txt and how to make Google ignore pages. It is about making it ignore small parts of the page, or transforming the parts in such a way that it will be seen by humans and invisible to robots.
There is a simple way to tell google to not index parts of your documents, that is using googleon and googleoff:
<p>This is normal (X)HTML content that will be indexed by Google.</p>
<!--googleoff: index-->
<p>This (X)HTML content will NOT be indexed by Google.</p>
<!--googleon: index-->
In this example, the second paragraph will not be indexed by Google. Notice the “index” parameter, which may be set to any of the following:
index — content surrounded by “googleoff: index” will not be indexed
by Google
anchor — anchor text for any links within a “googleoff: anchor” area
will not be associated with the target page
snippet — content surrounded by “googleoff: snippet” will not be used
to create snippets for search results
all — content surrounded by “googleoff: all” are treated with all
source
Google ignores HTML tags which have data-nosnippet:
<p>
This text can be included in a snippet
<span data-nosnippet>and this part would not be shown</span>.
</p>
Source: Special tags that Google understands - Inline directives
I work on a site with top-3 google ranking for thousands of school names in the US, and we do a lot of work to protect our SEO. There are 3 main things you could do (which are all probably a waste of time, keep reading):
Move the stuff you want to downplay to the bottom of your HTML and use CSS and/or to place it where you want readers to see it. This won't hide it from crawlers, but they'll value it lower.
Replace those links with images (you say you don't want to do that, but don't explain why not)
Serve a different page to crawlers, with those links stripped. There's nothing black hat about this, as long as the content is fundamentally the same as a browser sees. Search engines will ding you if you serve up a page that's significantly different from what users see, but if you stripped RSS links from the version of the page crawlers index, you would not have a problem.
That said, crawlers are smart, and you're not the only site filled with permalink and rss links. They care about context, and look for terms and phrases in your headings and body text. They know how to determine that your blog is about technology and not RSS. I highly doubt those links have any negative effect on your SEO. What problem are you actually trying to solve?
If you want to build SEO, figure out what value you provide to readers and write about that. Say interesting things that will lead others to link to your blog, and crawlers will understand that you're an information source that people value. Think more about what your readers see and understand, and less about what you think a crawler sees.
Firstly think about the issue. If Google think "RSS" is the main keyword that may suggest the rest of your content is a bit shallow and needs expanding. Perhaps this should be the focus of your attention.If the rest of your content is rich I wouldn't worry about the issue as a search engine should know what the page is about from title and headings. Just make sure RSS etc is not in a heading or bold or strong tag.
Secondly as you rightly mention, you probably don't want use images as they are not assessable to screen readers without alt text and if they have alt text or supporting text then you add the keyword back in. However aria live may help you get around this issue, but I'm not an expert on accessibility.
Options:
Use JavaScript to write that bit of content (maybe ajax it in after load). Search engines like Google can execute JavaScript but I would guess it wont value any JS written content very highly.
Re-word the content or remove duplicates of it, one prominent RSS feed link may be better than several smaller ones dotted around the page.
Use the css content attribute with pseudo :before or :after to add your content. I'm not sure if bots will index words in content attributes in CSS and know that contents value in relation to each page but it seems unlikely. Putting words like RSS in the CSS basically says it's a style thing not an HTML thing, therefore even if engines to index it they wont add much/any value to it. For example, the HTML and CSS could be:
.add-text:after { content:'View my RSS feed'; }
Note the above will not work in older versions of IE, so you may need some IE version comments if you care about that.
"googleon" and "googleoff" are only supported by the Google Search Appliance (when you host your own search results, usually for your own internal website).
They are not supported by Google's web-search at all. So please refrain from doing that and I think that should not be marked as a correct answer as this might create ambiguity.
Now, to get Google to exclude part of a page, you will need to place that content in a separate file, such as excluded.html, and use an iframe to display that content in the host page.
The iframe tag grabs content from another file and inserts it into the host page. I think there is no other available method so far.
The only control that you have over the indexing robots, is the robots.txt file. See this documentation, linked by Google on their page explaining the usage of the file.
You basically can prohibit certain links and URL's but not necessarily keywords.
Other than black-hat server-side methods, there is nothing you can do. You may want to look at why you have those words so often and remove some of them from the site.
It used to be that you could use JS to "hide" things from googlebot, but you can't now that it parses JS. ( http://www.webmasterworld.com/google/4159807.htm )
Google crawler are smart but someone that program them are smartest. Human always sees what is sensible in the page, they will spend time on blog that have some nice content and most rare and unique.
It is all about common sense, how people visit your blog and how much time they spend. Google measure the search result in the same way. Your page ranking also increase as daily visits increase and site content get better and update every day.
This page has "Answer" words repeated multiple times. It doesn't mean that it will not get indexed. It is how much useful is to every one.
I hope it will give you some idea
you have to manually detect the "Google Bot" from request's user agent and feed them little different content than you normally serve to your user.
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.