(First, I want to say that I am very much in favor of accessibility in general.)
There is a page on our website whose entire purpose is to quiz a student on what is depicted in a picture. That is the central activity on that page. Obviously, that won't work for blind people. The picture supports zooming, color blindness, and high contrast so as many people with vision problems as possible can use the page.
If I were to describe the picture in alt text or aria then I'm sure some students will discover that and be able to easily cheat. I do have alt text on the picture describing it in general terms.
I thought I read that there is an exception in the WCAG guidelines for "quizzes" but I have been looking for it without success. Can someone point me to where in the standard this situation is addressed? We are trying to pass as much of Section 508 as possible and have an explanation for anything we can't achieve.
You are probably thinking of the third bullet point in the list of exceptions for WCAG 1.1.1
Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
Is there an alternative way to test the student for this question? Or if the test question is purely visual, does a student have the option of opting out of the question without a penalty of their test score?
Related
I am looking for a way to mark some text as WCAG compliant or somehow otherwise exclude it from automated accessibility tests.
Quite often WCAG requirements state that certain criterion has to be met unless there's a good enough reason otherwise. In my case it is a placeholder text in a search input field. The field has an accessible label below it. The placeholder text is not functional and is added purely for decorative purposes as it is currently the standard in the web design industry to have it. As the text bears no functional purpose - the contrast WCAG requirement doesn't need to be met. Indeed, having the placeholder text with quite low contrast is required - if it is too dark it would appear as if there is already some input in the input field.
However, whenever I run an automatic check it (reasonably so) picks up the placeholder text as a colour contrast problem. That creates a business issue - as getting no warnings at the automatic tests is one of the client's accessibility requirements.
Android apps seem to have a flag like "IMPORTANT_FOR_ACCESSIBILITY_NO ", which would have been sufficient for this issue. Is there some equivalent for JavaScript Web Apps?
Short answer - no, there is no way to hide placeholder text from accessibility checkers without hiding the whole field (aria-hidden="true") which is not an acceptable route as you can imagine.
The one question you should be asking is why have placeholder text at all if it offers no purpose other than decoration? (can you not make the form more presentable another way)
Either make it high enough contrast (#767676 on white is 4.5:1) and italic (the only time italics are suitable from an accessibility perspective) or get rid of it entirely.
If you have correct associated labels with each input field then placeholder text should only be used to convey extra information such as formatting (e.g. enter date in format DD/MM/YYYY).
Side Note - if you do add extra information to a field via the placeholder, such as how to format a date, then make sure you also add the information to the label and use a 'visually hidden' class to hide the content of that text as screen readers often ignore placeholder text and the information is useful to none sighted users.
Think of it this way:-
John has low contrast perception problems (the point of contrast of 4.5:1).
John encounters your form on a website and can see some really feint text.
John strains his eyes only to realise the text offers no useful information.
You have now added 1 minor annoyance to your site that could reduce sales conversions for clients like John. (I know it is only minor but our goal is to remove barriers to a sale / enquiry at every stage.)
Worse yet, if John cannot make out the text at all he may think it conveys important information and be uncertain as to what he needs to enter, causing him to abandon your form entirely.
I'm trying to understand how this may be possible to achieve in order to make it more clear to the end user with disabilities.
What I'm trying to do is to hide some partial text that is provided by default and replace it with another piece of text for users with disabilities.
For example:
<span id="one">ACCESSIBILITY CHECK</span>
<span id="two">Accessibility check</span>
As you see, the first part(#one) isn't accessible. I want to hide second(#two) from default users and the first one(#one) from users with disabilities.
The first part - hiding from default users - I know how to achieve, but the second part not. I read about aria-hidden="true", but really not sure about it in terms of cross-platforming and the meaning it self.
It should be obvious that reading text with all capital letters isn't best experience for a user with disabilities. I want to target specific this sensitive aria and make it much more comfortable for disabled people who use assistive tech to read it
There are more people suffering from dyslexia (1 in 10 people) than blind people.
Using capital letters will affect people with dyslexia more than blind people. And there's no algorithm to detect dyslexic people.
There's no aria-dyslexic attribute. Sorry.
If your question only concerns screenreader users:
<div aria-hidden="true">Not visible on a screenreader</div>
<div class="sr-only">Not visible on a screen</div>
This uses bootstrap sr-only css class
I really do not understand why you would want to do this and make more work for yourself to maintain alternate content. Create one accessible version of your content that conforms to WCAG. Trying to display different content to users of certain assistive technology presumes to know exactly how they will best browse your site and the details of their disability. In essence, a solution like this is segregating your visitors into distinct groups, but the line between those groups is gray, not black and white. Again, just follow WCAG with one set of content.
A client asked me about using Vuforia in order to recognize logos on the shop windows. Basically, they want to use logos as a QR.
Is this idea viable? Will it work pretty well? Can you tell my some alternatives to Vuforia about this?
Recognizing logos is hard.
Basically all image recognition algorithms rely on the same principle: trying to recognize "interest points" of the image. These interest points can for example be blobs or corners; in short, we want to look for places in an image where "things happen", compared to (for example) a large solid area painted in the same color where there is not much information to grab.
This comes to trying to recognize discriminant "details" of the image.
When applied to logos, this method tends to fail due to the fact that logos often don't have enough of such "details". Take the Nike logo for example: if corner detection is applied to it, it will only find 2 corners (the 2 ends of the accent). Blob detection will probably give no result at all. This is an extreme example, as the Nike logo is really simple, but even on more complex logos there will often not be enough details for recognition to work.
As for Vuforia: it works in this exact same way, and their web interface (Vuforia Target Manager) is very clear about it: when you upload an image on it for recognition, if there are not enough details on it, it will either warn you that results may be poor or simply reject the image.
To conclude: you can run some tests, it's still the best way to be sure of it, but I wouldn't expect great results. It will probably work for detailed logos, and fail on simpler ones.
Hope this helps!
The sources I've read on making web pages accessible provide conflicting information on whether the 'title' attribute is actually useful. Some claim that it's best practice to give a web control a title attribute containing a more detailed explanation than the visible text on the control provides. Others claim that the default for most screen-readers is to ignore title attributes, so the attribute is useless in practice (except for providing tooltips for sighted readers). So, what do you folks recommend?
Not all screen readers ignore titles but some do. This is one of those areas though where it is best for you to include it as those who can get that content will. Plus search engines love title tags.
I'm actually encountering this problem with another Stack Overflow user right now in this question. Specifically, the reasons for a verbose title are:
A good title communicates to your visitors a lot of information about what the page is about
Google places higher weight on text within the title tag
However, this is lost on the user when they get to your page and have no idea what's going on just because you decided to game a search engine. Take Stack Overflow, for instance. A 50 word title may be good for Google, but how would you feel as a user if this question had the following title:
Should I make the Title Attribute Longer In Order To Acheive a Higher Ranking on Google, or Should I Make it shorter to make it accessible and not drive my Users Crazy?
In the end, while Google does matter; it doesn't matter more than keeping your user on your site once they are there; not to mention the benefit of a verbose title tag is lost on accessibility.
This website has a great article on the subject, and they write:
[...] The second reason has to do with SEO. Search engines need different information to rank the results of a particular query. Page title is one of the more important pieces of information they use to gauge how relevant your page is to a particular search term. This doesn’t mean you should load as many keywords as possible into the title — that defeats the first benefit — but you should ensure that each title succinctly describes the content of the page, including a couple of words you think people will search for. (Emphasis Added)
I use title on any links from my website as it is recommeneded by WC3 as per accessibility guideline 13.1 See http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-meaningful-links
For a lot of these accessibility issues bear in mind that what is not used now by an application may be used in the future so it's best to err on the side of doing too much rather than the bare minimum.
I understand that some countries have laws regarding website accessibility. In general, what are the minimum requirements that a website must meet to be accessible, regardless of country? Or, in lieu of minimum requirements, what are some specific things that websites should have to make the accessible?
W3C publishes Web Content Accessibility Guidelines:
http://www.w3.org/TR/WAI-WEBCONTENT/
If you want a quick summary list, look for the yellow-highlighted lines in that document. Each guideline is also broken down into specific requirements ("checkpoints") in one of three priorities - to claim any kind of accessibility under this scheme you must satisfy all priority 1 checkpoints, but they're "necessary" rather than "sufficient" conditions.
Looking at your pages in lynx is also a good measure - if it won't render in text, chances are good that a screen reader will have a difficult time of it too.
I recommend A-prompt for testing of Accessibility.
It is free and it can really help.
I also recommend Mark Pilgrim's online text - Dive into Accessibility.
It's not a binary question, and there's no silver bullet. Making sure you follow at least the basics of WCAG and testing in a couple of screen readers and without the mouse will probably be the most effective use of your time. If at all possible, test with real people with real disabilities, they have a perspective that is hard for fully-abled people to attain.
Well, obviously the law in different countries varies vastly. In the UK, for example, we don't have any specific web-accessibility laws, but no service is allowed to discriminate against someone with a sight or hearing impediment, insofar as it relates to functionality.
In light of this, a simplistic way to design would be to ensure that your website is readable by screen-readers, can be tabbed through successfully and in a logical order, and allows the scaling of screen elements (including images and font sizes) correctly for those who require web-pages to be magnified.
In addition, your website should have functionality fall-backs in place for any JavaScript and Flash, such that if they were turned off (such as is the case in many screen readers) all functionality is still usable. Don't rely on WAI-ARIA for JavaScript accessibility, as it isn't standardised, and it isn't widely supported.
Of course, this doesn't necessarily cover every possible law, but it's a good starting point. If your website meets the above 'criteria', you're likely to have a good level of accessibility. There is a test for accessibility, of sorts, following WCAG but it's by no means 'conclusive' for what is an acceptable level of accessibility in each individual country.