How do I override the accessibility feature in mathjax that puts a blue box around equations? I just want it to respond like normal text when clicked, ie no blue box.
For example, click on an equation here:
http://jsfiddle.net/dandiebolt/AqDCA/
\(ax^2 + bx + c = 0\)
You are probably describing the native browser behavior that adds an outline to an element that is in focus (default styling depends on the browser). MathJax elements can be put into focus by clicking because they are added to the tabindex for accessibility purposes.
So first piece of the answer must be: don't do it. Don't abandon accessibility.
If you don't like the default browser outline, design the heck out of it! All this needs is something like
.MathJax:focus, .mjx-chtml:focus, .MathJax_SVG:focus {
outline: 1px solid gray;
}
(to cover MathJax's HTML-CSS, CommonHTML and SVG output.)
But this is an ugly world so if you are brutally forced to abandon accessibility, you can disable the tabindex.
To quote from the MathJax documentation:
inTabOrder: true
This controls whether math elements should be included in the tabindex. If set to true, MathJax will add tabindex=0to the output. If set to false, it will add tabindex="-1".
Developers are strongly discouraged from initially disabling this (by means of configuration) as it will render the menu inaccessible.
In other words, unless you disable the menu, don't damage its accessibility. (And also, don't disable the menu; it's critical for accessibility, especially with enhancements in the upcoming v2.7 release.)
Related
I am hoping someone could enlighten me on exactly what is the fix to pseudo classes and content negatively impacting screen readers.
For example, if I have this piece of code in my SASS file:
[bag-total]:before{
content: attr(bag-total);
}
My intent here is for the screen reader to read the value of the attribute or the total amount in the users' cart that he is about to purchase.
The problem right now is the screen reader is not reading the number of items in total inside the shopping cart.
The :before and :after pseudo elements are used in the "accessible name" computation as defined here - https://www.w3.org/TR/accname-1.1/#step2. Specifically, step 2.F.ii
The process looks complex but if you think of simple cases, such as a button, the accessible name is essentially the text label of the button. However, a button that displays "read more" might make sense for a sighted user because they can see the context around the button, but for a visually impaired user that is using screen reading software, "read more" might not be sufficient. It's possible to add more context to the button label using ARIA attributes. The additional context is not visually displayed but is used in the "accessible name" computation, which is why that process looks complex.
The same is true if your button just displays an icon. There is no visible text but you need some way to describe the button's icon so that the "accessible name" will make sense.
If you use :before and :after pseudo elements to add more context to your element, that additional context needs to be included in the "accessible name" computation.
Now, all that being said, I'm not sure what kind of "fix" you're looking for. You didn't really state what the problem is you're trying to fix.
It looks like the CSS and user-agent specifications support what you're trying to do here, but inconsistent browser support may ultimately prevent it from working well.
I tested your method using NVDA on Windows with several browsers, and Internet Explorer was the only one that had difficulty. IE still has a fairly sizeable user-base, so it's probably worth supporting if you can.
Unfortunately, I can't see a good solution to your problem unless you want to use JavaScript or a server-side scripting language. Both of these methods add the content to the DOM, whereby CSS doesn't.
This page has some good information on the accessibility of pseudo-elements that seemed to confirm what I was seeing in my own testing.
https://tink.uk/accessibility-support-for-css-generated-content/
For example, when a modal dialog is opened up, there can be irregular blue highlight around the modal dialog. For accessibility, it may be good, but while it helps 5% of users, to the other 95% of users, they will see the irregular and a bit obtrusive blue outline.
Does it comply with ARIA / ADA guideline to make the blue outline disappear for the general users, while let the accessibility browsers / readers force a blue outline? (by the rule of the browser's enforced CSS).
This is defined in WCAG 2.4.7.
2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)
The focus indicator does not provide much benefit to screenreader users which often already benefit from improved visual and keyboard focus (assuming they can see)
People with low vision may use standard browsers without any other assistive technology and want to know where the keyboard focus is currently set. The keyboard focus is also useful for people with motor deficiency
But, there's nothing that says in accessibility guidelines that when you open a modal dialog, you should focus the whole dialog. You can perfectly focus the first interactive element (button or link) and make it the first element in the dialog.
Note that talking about accessibility, you are not helping 5% of people but according to WHO from 15% to 20%.
You can also perfectly, without removing the outline, make it more subtle.
I'm displaying mathematical expressions in a webview (using jqmath library and some CSS). One requirement is that expressions should be centred, and here's what I use to achieve that:
<html><head><style type='text/css'>html,body {margin: 0;padding: 0;width: 100%;height: 100%;}html {display: table;}body {display: table-cell;vertical-align: middle;text-align: center;}</style></head><body><p>here goes the expression</p></body></html>
Since rendering math takes some time, the webview is hidden while the expression is rendering, and displayed only when it is ready (once the WebViewClient's onPageFinished has been called). This worked well until Android 4.4.
The problem with the new webview seems to be that it only applies CSS when it is visible on screen. So after revealing the hidden webview, the expression first appears in the top left corner, and only after ~0.1 seconds "jumps" to the center. This looks ugly, since I have to display many expressions in quick succession.
A related problem is described in this question: width:100% in CSS not rendering well in Android 4.4. The asker was able to solve his problem by removing the display: table; from html, but that doesn't work in my case.
So is there a way to either:
(a) force the new (Chromium-based) webview to render content while it is not visible, or
(b) display the content at the center from the beginning (without first displaying it in the top left corner).
It is not true that the KK WebView applies CSS only when visible on screen:
the WebView will not size itself if it has visibility set to GONE because the Android framework will call layout-related methods on it (like layout and onSizeChanged). This might be what you're seeing. Try setting the visibility to INVISIBLE instead.
WebViewClient.onPageFinished is not a reliable trigger for showing your WebView. What the callback really means is that the resource for the main frame had been loaded from the network. Unfortunately there never was a reliable callback that would tell you 'your content is ready to be displayed' - what you're describing probably happened to work because of particular timing. The most reliable way to not show unfinished content would be to do so in the HTML/CSS.
you might be using WebView.loadDataWithBaseUrl to load your contents into a new/blank WebView - this API is has an effect similar to re-writing the page's content (rather than issuing a 'real' navigation) and can result in weird layout. If possible use loadData or loadUrl. If neither of those are feasible try calling loadUrl("data:text/html,<body style=\"margin: 0px;\"/>"); before loading the real content (wait at least till you get an WebViewClient.onPageStarted callback for that bootstrap URL).
you might be setting height to WRAP_CONTENTS. This is very unlikely to cause the issues you're describing, but it would be good to rule out. Try setting a width of MATCH_PARENT and a height with a fixed number of pixels.
I hear of advice of making the .hidden class not as a
.hidden { display: none }
but make it width and height of 1, and using clipping, etc, to make the element as if it still exist on screen but the content is just not visible.
But isn't it true that when we use JavaScript to hide something, the purpose of that element is done, and we want it to not show on the screen and not visible to the screen reader either?
Case 1: For example, if it is an input box, and inside the box there is a grey line of text "Enter keyword". When the user actually clicks on, or keydown, (or using the input event), now we have a JavaScript handler to hide the "Enter keyword" text, because it is just a grey prompt inside the input box. In this case, shouldn't the text be completely hidden, using in fact a display: none, so that even screen reader can't read it? (the user have learned enough to start typing, so the prompt shouldn't really still be there to be read by screen reader, right?)
Case 2: If it is a pop up bubble, for error message, or there is a link "enter your email for our subscription", and it will pop up a bubble, then when the bubble is closed, shouldn't the bubble be really closed totally using display: none? The screen reader shouldn't really still be able to read those content out for a bubble that is done and closed.
Case 3: The only case I can think of is a small fraction that the "hidden" should be available to a screen reader is: it is for a bubble for extra information, such as for the product rating (how many stars out of 5), or extra help info that can pop up when the mouse hover over some "?" icon or link. But even in this case, won't screen readers actually read out "link to more info" or "link to show rating", that is in the alt or title of the tag, and not read the pop up info until the user pops it open?
So my question is: shouldn't there be really two types of hidden. One is display: none type that screen reader shouldn't see (make it the .hidden class), and the other is width: 1px; height; 1px that the screen reader can see (or will read out) (make this the .a11y-hidden class), and whether type 2 might be far less often than type 1?
Mostly, that's it.
EDIT 2014: I switched to the clipping method from TJK at Yahoo! (because of hidden span into a link where only an <i>con is visible).
I prefer position: relative; left: -5000px over clipping 1x1px, I know that Yahoo! team only use the latter but the aim is the same.
Also I'll call it .visually-hidden (from Twenty Sth theme in WordPress and other CMS and frameworks). .a11y-hidden would mean the contrary: it's only visible (perceivable) by screen readers and in plain HTML.
Tabs content, error messages that didn't occur yet (your Case 2) shouldn't be perceived by anybody. A screen reader user will have to click on a tab to show its content as everybody else.
Note: display: none AND visibility: hidden elements will be ignored by screen readers. And also some of them (VoiceOver on OS X in particular) will ignore an element with height: 0, etc
Relevant article : Invisible Content Just for Screen Reader Users from WebAIM
Case 1: the important part being read out is the label associated with for/id to the form field.
If you use a keyboard to navigate from field to field, this text will have disappeared when you'll have focused it and it won't be visible to users that zoom at x00%. HTML5 introduced the placeholder attribute that has the same role as this prompt (this is NOT a replacement for label, this is a hint but few people read one of the HTML5 doc alas) and can still be passed to screen readers even if it's visually hidden.
Case 3: this information should be coded in HTML in an accessible manner and so you wouldn't need to visually hide information out of the viewport or in a pixel.
alt text is the preferred manner (or even better a visual with some real text by its side, while avoiding too much clutter. I've no training in ergonomics and this will often annoy webdesigners that want to remove everything from a page ;) ).
title attribute should only be used on links and you're never certain a screen reader will choose to read them. It's a personal matter and setting on a per site basis. They can be so annoyed by some sites that they'll disable these titles everywhere... Though, it's still one of the best techniques to add information if for some reason you can't do it otherwise.
How do I use this .visually-hidden class?
quick access links (to content, navigation and search input) when they don't appear in the mockup. When focused, they'll be brought to screen as in http://www.nanomatrix.fr/ (press Ctrl-L or Cmd-L, tab half a dozen times on Windows and enable tabbing through links in Safari and/or OS X. See on upper left the 3 links)
on labels when for some (bad) reason, they're not in the mockup I receive. Better have a fix (it's a good one) than doing nothing to improve accessibility when it wasn't thought of beforehand...
on captions of tables, because most of the times showing them is a no from client, external webdesigner, etc
on a span with information next to a font icon when it's coded in a performance manner but not very accessible. There are many ways of using a font icon, I'm only speaking of a few use cases
Theres a lot going on here that needs to be addressed.
Firstly, and ideally, the grey text in the input box should be handled by the 'placeholder' attribute. The browser will give the user a consistent and expected behaviour, and its also easier for you to code!
Secondly, for accessibility ideally all inputs should always have labels. This is so that the input is described correctly to screen readers. You can hide them if the design doesn't call for them (some websites only use placeholder text, but that doesn't mean they shouldn't) be there) - which brings me to my third point - hiding content on screen but not from screen readers:
{display: none} will hide information on the screen AND from screen readers. It's basically a way of making something disappear - for everyone. This is where the .visuallyhidden class (or similar) comes in - its a way of adding context (extra information) to the DOM that will be picked up by screen readers but not read by sighted users and it's a technique used very often to make pages more understandable to AT users without breaking a layout or design of a page.
Its a good idea to use a tried and trusted class, such as the one inside the HTML5 boilerplate, as getting it wrong could penalise you on Google (for trying to blackhat content) or create problems with some screen readers on some devices (e.g. iOS) - position:left and text-indent is not a good solution for a number of reasons, so stick to the 1px and clipping technique.
[Please only post an answer if you know the answer really well -- if you post an answer such as "I think it is easy to style it in CSS", then it is a guess and not a real answer, and it will make lots of people skip this question because it is marked as "answered"]
[I know the Share button is to be phased out, replaced by the Like button, but the program management still wants to use it as well as using the Like button]
I see fairly often that the Facebook Share button is faked by using an icon, as a background, and the text "Share" as a "button" -- the icon + text is faked to be 1 button.
Example:
http://www.youtube.com/create_detail/GoAnimate
http://www.pcmag.com/article2/0,2817,2381106,00.asp
The surprising thing is, it actually looks good on FF as well as IE 7. And the top link uses Tahoma font, while the second one uses Verdana for Windows, and "Lucida Grande" for Mac.
Question 1: what is it not made into an image? Because as we all know, an image looks the same almost every where. If you need to align the icon with the text, for all different fonts on different platform - Mac, Win 7, Win XP, Vista, Linux, IE 7, IE 8, FF, Chrome, and make the background of the text blue so that it looks like part of a button, it is going to be hard. Different fonts have different top space and bottom space (the "leading" as in printing terms), so it is hard to align the text well with the icon, and also hard to make the font not to look like grainy text on all platforms.
Question 2: is there a standard library or standard method to do it?
(the long existing <fb-share> as XFBML actually gives you an <a>, with the background icon, and then a <span> inside the <a> tag containing the text "Share". So it is actually just a square icon + text, but such as the second link above, they will fake it as a button. Maybe that's why even when it is not XFBML, some people still show the button this way instead of a good old image)
Update: also, it is hard because they usually are just <span>, and you can't specify a width for a <span>. Also, it has double borders to make it look like 3D, but it looks like 1 border is real CSS border and 1 border is by using the Sprite underneath.
Update 2: By the way, of all the Facebook Share button page that still exist on web, I never saw one with a Bubble with a count... this is getting more mysterious...
There are three good reasons for doing it this way:
Reuse: You can use the same icon on several different buttons, regardless of what the text content of the button is. This means you only have to download the icon once, which saves on bandwidth (see below) and means you don't have to make a different button image for every button you want to provide to the user. This is especially important on multilingual sites, as I'm sure you can imagine.
Bandwidth saving: The small icon used to decorate the text button is a lot smaller than an entire button graphic would be and therefore consumes less bandwidth to download it. While for one button this might not amount to much, it all adds up, especially on a site with potentially hundreds of different buttons that gets the kind of traffic that a site like Youtube or Facebook might get.
Accessibility: Image buttons take some additional work to make them accessible (the addition of an alt tag for example) which can get overlooked by web developers in a hurry. Text buttons are accessible by default because they're, well, text.
As for how to do it well, there's any number of approaches. You could use the <button> tag, though this has its own set of issues in IE, you could use <input type="button" /> and give it a background and padding (so the text doesn't overwrite the background) but that approach will require javascript to make the button actually do anything, <input type="submit" /> (similar to buttons but handling them is done server side instead of with javascript), or you could style <a> tags to look like buttons by giving them a background, white top and left border, black bottom and right border, etc. I'm sure there's others as well that I can't remember off the top of my head.
UPDATE: The OP added an update regarding spans and width. By default, no, you can't give a span a width. If you give it padding you can create space inside for adding the icon as a background image, of course, but if you need to explicitly give a span a width you can do it by setting its cisplay CSS property to block or inline-block (the latter requires a modern browser to work)