For general accessibility and section 508 compliance, we need the ability to add alt attributes to rendered charts. Even an empty alt would be sufficient.
For outside reference. The ZingChart image map does not contain an alt tag. This has been updated and will be pushed out in the newest release v2.6.1. This release may be about 2-3 weeks from the time this answer was published.
Note This problem was easier to solve with direct contact through support#zingchart.com. While we don't want to discourage public outreach, the fastest way to reach us is through support#zingchart.com. It goes directly into our ticketing system.
The (alt=””) will pass the test and tell screen readers it is decorative and not informational.
Related
We have a project at my work at the moment around ensuring we meet accessibility standards on our website.
Our emails are built using Salesforce Marketing Cloud layouts. Does anyone know how we can see or test how 'accessible' they are?
I can test using ReturnPath to see how they render on various devices and that gives me results for colour blindness, but I'm not sure how to test how well they would or wouldn't work with a screen reader for example
Emails are a tough one from an accessibility perspective. We are still stuck using tables for layout even in 2021!
We can't use WAI-ARIA and CSS is very limited.
As such I have a smaller checklist for emails that covers the important stuff we can control.
The main things I would look at are:
Reading order
Make sure that the email reads left to right and then downwards (assuming the language is a left to right language, otherwise reverse it)
Use headings
Email marketers often just style normal text instead of putting proper headings in. Make sure headings are in fact <h2> to <h6> with a single <h1> explaining the purpose of the email at the start.
Also make sure that the headings do not skip levels (so don't go from <h2> to <h4> for example).
Colour contrast
The exact same rules for websites apply to emails. I would recommend running the colours through the Web Aim colour contrast checker for your text and background around the text, button backgrounds and text etc.
Alt Attributes
Alt attributes on images is the big one you need to check for especially in emails where images might be the only content within a hyperlink. As you can't use aria-label or visually hidden text in an email alt attributes are the only way you can make a link have meaning if it contains an image (plus as email clients block images it means there is meaningful text for everyone else not just screen reader users).
Meaningful Link Text
Along the same lines make sure links do not just say "Read more". Instead make link text meaningful e.g. "Read our article on X Y Z".
Use a descriptive subject line
This one is the only one that is "difficult" as a marketer. You want subject lines to intrigue people to open the email, however for people with cognitive impairments cryptic subject lines can be disturbing / confusing etc.
Getting the balance between "giving the game away" and meaningful subject lines is difficult, if unsure err towards meaningful (it may help your open rate / conversion rate anyway so A / B test it!)
View in Browser
Due to the limitations of email clients the best way to ensure accessibility is to have a custom "view in browser" link in the email (as salesforce etc. are very unlikely to do a good job of the browser versions of their emails).
That way you can use WAI-ARIA, visually hidden text etc. and mark the page up properly, complying with WCAG 2.1 (and very soon WCAG 2.2) requirements.
Obviously I am aware of the amount of work this entails but once you have a template and components built that are accessible it does become much easier.
Testing
Personally I would just test manually, but I am sure somewhere out there an email testing service exists similar to Axe Accessibility Checker.
But given the length of a typical email I would say a manual check will only take 2 minutes once you know what to look for so a service may not be worth it.
You could always copy and paste the email HTML into a file and save it with a .html extension and then open and test it in a browser / accessibility checker. But you might get a load of issues you can't resolve due to the use of tables for layout.
Finally - learning to use a screen reader takes less than an hour, grab NVDA or VoiceOver and test the email yourself, if you can understand it and access all the same information as everyone else then send it!
Does anyone know how I should handle aria-labels on link labels that repeat dozens of time on a page? My website accessibility checker tool keeps flagging these elements as using the same link text for these labels and they require unique aria-labels. Problem is, all of the links go to the same generic pages and am not sure how to make the aria-labels specific enough.
Has anyone dealt with anything like this before and how did you handle it? I imagine I'd need a JS solution to inject aria-labels, but before I invest in a JS resource doing this for me does anyone know how I can make these specific enough to pass the checker but not confuse screen readers?
Screenshot of category labels for each article
In this case, it is correct to hide all duplicate links except for the first element that contains these labels
You force people with disabilities to navigate through all the same links using keyboard navigation, this is also bad for a screen reader
1.) Hide any duplicate labels from your screen reader
aria-hidden="true"
2.) Hide any duplicate labels from keyboard navigation
tabindex="-1"
Note! don't forget to leave one unique link! You can also hide everything and add them to context under elements or above elements. When I say hide, I mean the above methods.
It's easy to check for accessibility, close your eyes and imagine you click on a tab and hear (in a screen reader) a re-link through every two elements! This is annoying isn't it?
There is no need for aria-labels and what you are doing is not an accessibility fail. You have to bear in mind the automated accessibility checkers are dumb (and in this case quite possibly wrong) and are only there to offer guidance on common accessibility fails.
The main reason you are seeing this is that the accessibility checker thinks that this is text like "read more" that is not descriptive of the end-point. It should pick up the fact that the end-point is the same but it obviously does not.
Using the same link text for links that go to the same page is encouraged:
It is a best practice for links with the same destination to have
consistent descriptions (and this is a requirement per Success
Criterion 3.2.4 for pages in a set). It is also a best practice for
links with different purposes and destinations to have different
descriptions.
Source: https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html
Also one of the checks for success criterion 3.2.4 - Consistent Identification is:
Check that this associated text is identical for each user interface
component with the same function.
Source: https://www.w3.org/WAI/WCAG21/Techniques/general/G197.html
Assuming your articles are marked-up correctly a screen reader user could skip between headings (<h2>s for example) in order to not hear the same category links. This is one of the primary ways a screen reader user will navigate a page (via headings).
For this reason the categories should be AFTER the heading in the HTML so that they are read out after the heading.
You could place the heading visually after the tags using techniques similar to those in this answer I gave. This would be acceptable for "logical tab order" in my opinion so you wouldn't fail there.
Your only other option would be to use aria-hidden="true" and tabindex="-1" on your category links to hide them from screen reader users and take them out of the tab order. If you did this you would need to ensure a categories list is available at the side of the page.
Personally I would go with the first option as the categories information is useful to screen reader users, the fact the links repeat themselves over and over if I search by links would indicate they are categories to me when using a screen reader anyway.
In Google reader(R.I.P) we could select some interesting links by a special tag and then make public them and show links on our blogs or websites.
Is there a way to create this by Google reader alternatives like Inoreader or Feedly or AOL reader or etc?
I should probably start by saying that I'm the BDFL of Inoreader, but I feel obliged to answer you. If anyone thinks my answer is inappropriate or that this can be achieved with one of the other mentioned options, feel free to bash me in the comments :)
Yes, you can do that in Inoreader.
Since you are familiar with Google Reader, you shouldn't have much difficulties starting up with it, but if you have, here's a quick guide to get you started.
Depending on what you need to achieve the option you want is accessible via right-click on a folder or a tag:
Then in the dialog that pops up, you will see an Export option. Click it and you will get 3 links - for RSS feed, HTML page (what you need) and a public OPML file (for folders only):
A few notes on folders and tags:
Folders are used to group sources (RSS, social and other feeds) and content inside them is automatically populated from the feeds.
Tags on the other hand are mostly manually populated by you. When you read an article and you find it interesting, you can press "T" or click the label icon at the bottom of article to tag it. This behavior is almost identical in all major RSS readers. Working with tags in Inoreader is covered in detail in this blog post.
Now I said mostly before, because tags can also be automatically populated by Inoreader's Rules. Basically they works like your email filter. You can set up keywords or other conditions and tag articles automatically as they arrive. This feature is covered in this blog post.
Hope this helps!
Will the Googlebot "click" buttons on a Flex 3 site when it indexes it?
I've got a Flex 3 site. When the user clicks one of the buttons on my site, a panel opens and text appears. As the text is not immediately visible, will Google index the content in the panel? (I'm not cloaking or anything weird. It's just the normal functioning of the site).
Are there any Flex 3 developers out there who see Keywords listed in Google Webmaster Tools for text that is visible only after clicking a button?
Thank you.
-Laxmidi
Straight from google itself:
Q: How does Google "see" the contents
of a Flash file? We've developed an
algorithm that explores Flash files in
the same way that a person would, by
clicking buttons, entering input, and
so on. Our algorithm remembers all of
the text that it encounters along the
way, and that content is then
available to be indexed. We can't tell
you all of the proprietary details,
but we can tell you that the
algorithm's effectiveness was improved
by utilizing Adobe's new Searchable
SWF library.
Q: What do I need to do to get Google
to index the text in my Flash files?
Basically, you don't need to do
anything. The improvements that we
have made do not require any special
action on the part of web designers or
webmasters. If you have Flash content
on your website, we will automatically
begin to index it, up to the limits of
our current technical ability (see
next question).
That said, you should be aware that
Google is now able to see the text
that appears to visitors of your
website. If you prefer Google to
ignore your less informative content,
such as a "copyright" or "loading"
message, consider replacing the text
within an image, which will make it
effectively invisible to us.
In short I haven't actually seen this working on my own projects (though I don't target SEO) Adobe acquired Omniture an SEO company recently and the people at Google are smart, so I don't doubt this will be progressing nicely in the near future, more info and experiments can be found here:
http://www.flashnseo.com/
http://www.omniture.com/en/
I don't think there is a clear answer to this one since it's in flux and Google can't disclose exactly how their algorithms will work, but as stated in the other answer here I'd imagine if the information is still represented as text in the swf, they'll find a way to dig it up, in terms of how your site will handle deep linking, that's still on the developers (although I've got my fingers crossed that between Adobe and Google they're able to ease the pain on us).
I'm currently making a project where I need to print out a receipt on a receipt printer.
At the moment i'm using the CSS mechanism media=screen , media=print to indicate what to print.
Problem is of course the header and footer which can't be removed, as it is client browser specific.
So i'm wondering if anyone has another suggestion on how to do the printing. Preferbly without using too much IO.
Generally speaking, if you need precise control, your best bet is to have a pdf, or other doocument format that is generated from the server, for your printing. (if the machines printing receipts are controlled, and have word, than .doc (html with an output type) is the easiest method. There are a number of third party controls for generating PDF from server-side code as well. Hope this leads you in a usable direction, since you didn't specify if you controlled the client machines in use.
One benefit to PDF is you can use it as a hard archive, as well as being able to email receipts as an attachment.
The header and footer information (Assuming you're talking about the URL showing up at the bottom of a page) is client-side and there is nothing you can do to change that from server side.
If all of your printing is going to be done from inside your company, you could have a group policy created for Internet Explorer printing to remove these company-wide. You could also just have instructions on your page on how to change these setting manually.
Another option is to print with a 3rd party application, such as PDF, or print it directly from the server if that option is available to you.
Do you mean the page header and footer?
If that's the case, wrap the header and footer in IDs and create CSS tags to target them and give them a much simpler styling, or you can use the CSS element display:none to remove them altogether in the print css.
You could load the content you want to print into an iframe, focus on it, and print that. That way you'll have exact control over what appears on the receipt.
It'd take a small bit of javascript, but I've had success doing similiar things when I wrote a custom contract printer.
It's not an ASP solution, but may help:
http://code.google.com/p/jzebra
It's a java plugin that can bypass the header and footer stuff.