In a webpage there was a paragraph:Follow Us:Facebook,Twitter.The title was missing for social networking icons.When I inspected the code for the webpage, I saw :the title attribute value was missing:
Though the developers say that these icons are clear and self-explanatory,absence of title is not a good accessibility practise.Moreover,as I have highlighted the code is also not as per correct HTML standard.Please suggest what else might be the problem if the title attribute value is missing in the code.
There is no accessibility issue for a missing title attribute in this context (on an <a href>). Do not use it here.
https://www.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/
Situations in which the the title attribute is not useful due to lack of support:
Displaying information for web content viewed on mobile phone browsers. Typically in desktop browsers title attribute content is displayed as a tooltip. From what I could find, tooltip display is not supported in any mobile browser and alternative visual methods of accessing title attribute content are not supported.
Providing information for people who cannot use a mouse. Typically in desktop browsers, title attribute content is displayed as a tooltip. Although the tooltip behaviour has been supported for 10+ years, no browser (except IE10+ [on focusable elements]) as yet has implemented a practical method to display title attribute content using the keyboard.
Using it on most HTML elements to provide information for users of a variety of assistive technologies. Access to title attribute information is not supported uniformly by screen readers
Since the above is copied from my answer to your other question, and this question is not clear what element has the title, some more info...
https://www.paciellogroup.com/blog/2016/02/short-note-on-use-of-alt-and-the-title-attribute/
alt="" is a standardised indication to screen reader software that the is decorative and can be safely ignored. Testing by Powermapper from 2015: IMG with null ALT and non-null TITLE attributes found issues with alt="" + non-empty title.
Absence of an alt attribute results, in some screen reading screen reader software, not conveying the to users.
Note: Found this issue with JAWS 17 and Chrome 48 on Windows 10. Testing by Powermapper from 2015: IMG with TITLE Screen reader compatibility found no issues with this pattern.
Some browsers implement the HTML5 requirement that alt="" is equal to role="presentation" which results in the being removed from the accessibility tree, so despite there being a non empty title, the is hidden.
Related
I'm building a Web Extension that injects a local page and I reached a strange Chrome limitation on some websites: I can't set the iframe to be transparent:
Try this on GitHub.com (after login) or on Google:
document.body.insertAdjacentHTML(
'afterbegin',
'<iframe style="background: red" srcdoc="<style>body {background:none}">'
)
You'll see that the iframed page’s background (white) is shown instead of the element’s background (in this case made red to highlight the issue).
If you try the same code on StackOverflow or Twitter you'll find that the iframe is red.
I assume this is due to security but strangely it's even happening on this simple website that lacks any security header: https://sjmulder.nl/en/textonly.html
Firefox and Safari are not affected.
For anyone looking for a quick copy-paste answer: include a color-scheme meta header in the injected iframe. It must match the color-scheme header of the web page, if one exists. Do not add the meta header if a website does not have one. As this requires programmatic effort to figure out if such header exists a what the content value is, those steps are omitted, but once the scheme is known, the injection code would look something like this:
document.body.insertAdjacentHTML(
'afterbegin',
'<iframe style="background: red" srcdoc="' +
'<meta name=\'color-scheme\' content=\'light dark\'>' +
'<style>body {background:none}">')
Next a more detailed answer, and how I discovered it.
The screenshots show macOS in dark mode. If you go to OS settings and toggle the appearance between light and dark, this should alternate the white color and red color behind the iframe. Try and see if this happens.
After some experimentation, I discovered iff a website has a meta header for color-scheme:
<meta name="color-scheme" content="light dark">
as is the case with Github.com and sjmulder.nl, an iframe without matching header is only able to handle light mode correctly, and renders a white background if user device is set to prefer dark mode. I suspect this is because "major browsers default to light mode if not otherwise configured".
You can experiment with this and switch the color mode header on a test website to "light" (only) and "dark" (only) without specifying anything in the injected iframe; or define it in the iframe and not on the website, then switch the device color mode preference to see the effect. The conclusion I reached was the headers must match for iframe background color to get applied correctly.
I reached a strange Chrome limitation on some websites
When a website has not defined a color-scheme meta header and the injected iframe has not defined one either, there is no mismatch, and there is no issue, which is why this problems only presents on some websites. I also tried other browsers (Edge, Opera) and they have this same issue, at least on macOS. But it can be fixed in an extension by first checking if there exists a meta header on the page, and if yes, applying that same header to the injected iframe.
Read #neea’s answer for a broader explanation, but here's a quick fix that works anywhere: Add the CSS color-scheme: normal to the iframe, either via stylesheet or inline:
<iframe style="border: 0; color-scheme: normal" src="your-url.html">
Only do this if the iframed page will display correctly on both dark and white backgrounds. You might also need to set color-scheme: normal in your iframed page via meta tag, but this should not be necessary.
Why Chrome does this
Light schemes generally show black text and white background and dark schemes are the opposite. Chrome uses the color-scheme property to understand what schemes a website supports. The lack of it means it only supports the light scheme.
If the main page is being shown in a dark schemes and the iframed page isn't, with a transparent background you would get the iframed page’s black text on the main page’s black background.
This is a safety mechanism to ensure that the iframed content is still readable. If you drop it, you will need to manually ensure that the iframed page is readable on a dark background too.
Live demo
You can see that neither iframe has a background in both dark mode and regular mode.
Page only has one scheme, iframe never shows a white background: live link
Page only 2 schemes, iframe never shows a white background: live link
Following what #neea has said, which is true, I want to propose another code fix, since the color-theme fix doesn't do anything for me.
Since you use the iframe for a chrome extension, you simply need to have the iframe injected with a content script and then get the value of the page of the meta tag, which can be done easily with document.querySelector('meta[name="color-scheme"]')?.content
Personally, in my project I used react and react-frame-component, and I got it by inserting this into the head (I also use TS):
<meta
key="1"
content={
(document.querySelector('meta[name="color-scheme"]') as any)
?.content ?? 'light'
}
name="color-scheme"
/>,
I verify if the site has that tag, then I take and if not, it defaults to light mode.
This needs to be injected into your iframe HEAD. Then it will work for sites such as google dark mode or github.
Element.insertAdjacentHTML()
The insertAdjacentHTML() method of the Element interface parses the specified text as HTML or XML and inserts the resulting nodes into the DOM tree at a specified position. It does not reparse the element it is being used on, and thus it does not corrupt the existing elements inside that element. This avoids the extra step of serialization, making it much faster than direct innerHTML manipulation.
It has something to do with how chrome parses HTML and the order it uses.
I am relatively new to working with JAWS and trying to fine tune some discrepancies between Firefox and IE when working with it.
Currently, I have a crystal reports popup window that has two toggles, for example, one is for find. That once it's triggered, the user can type their search string. This div has an aria-role="button"as well as an aria-pressed="true/false" value. However, in IE11, JAWS is not reading back whether the button is pressed or not like Firefox does.
Any insight? Has anybody else hit this issue?
<div tabindex="0"
title="Find"
class="someClassName"
id="someID"
role="button" aria-pressed="false">...img...</div>
Note: I've replaced the lengthy classes and auto-generated ID.
It might be a JAWS bug. However, basically it is not good to do things like <div role="button">:
Do not do this:
<h1 role=button>heading button</h1>
Do this:
<h1><button>heading button</button></h1>
© Www Consortium, The second rule of ARIA use from here.
So, in your case I'd use a <button> rather than a <div>.
Actually, the first rule of ARIA use also applies and maybe is even more appropriate here:
If you can use a native HTML element [HTML 5.1] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property
to make it accessible, then do so.
I've read one place that aural stylesheets are no longer in use? Is there something that has replaced them? I'm sure something is being used to make things easier for those who are visually impaired?
If aural CSS is in use still, is there a way to specify what should be said in a specific place, similar to using "alt" for images? For instance, I'm using an iconfont for my logo. I'd like to be able to have the user hear the name of my company, but because it's just done with a span, there's no place in that particular span that indicates the words (I'm assuming here that the system reads the words displayed on the screen, and not all the code with it, so obviously this works better if there's actual text to read). Maybe include a content: 'whatever text you want' is added somehow?
The gist is that I'm working on a site about opera for a client, and the client would like for the content to be accessible to everyone. And obviously someone with visual impairment is going to be especially wanting to hear things.
1. Is there a replacement for aural?
Aural stylesheets have indeed been deprecated as of CSS3. Major browsers such as Firefox removed the implementation a while ago. There is still a speech media included, but I haven't seen any implementations so far (it just seems to be a proposal at this point).
Many people with visual impairments use screen readers and to a lesser degree refreshable braille displays to view the content, so you usually don't have to worry about a direct implementation of speech. Important points for that to work are:
People have to be able to navigate through your content using the
tab key
All relevant rich content such as images etc. need to have a text equivalent.
Your html should be semantic (have a look at the aria attributes)
2. How can you make icon fonts (and other non-legible items) accessible?
In this article on bulletproof accessible font icons they propose a pretty good solution:
Since the characters don't have any direct semantic meaning, you could include them in the :before pseudoclass of your span:
.logo:before {
font-family: YourIconFontFamily;
content: "★";
}
And then include the company name directly in the span:
<span class="logo">Your company<span>
According to W3 it's defined in CSS 2 - but is already been deprecated with CSS3. You also can have a look at the Speech module: http://www.w3.org/TR/css3-speech
You can use another span with the specific content only for the screen reader which would look something like:
<span aria-hidden="true">Here could be your company name</span>
Source: http://www.456bereastreet.com/archive/201205/hiding_visible_content_from_screen_readers_with_aria-hidden/
We are trying to use an #media print.css style sheet to enable a web page to print a set of Avery labels (6 up on a sheet - 4" x 3"). Generally a print media style sheet seemed like a perfect solution to having a page that looks like a list on screen, but when you print the list you get imprinting for Avery badges!
The challenge is in the details though. In addition to the fact that each browser seems to have unique interpretations of print styling and some of the rules just don't work. I've seen and studied most of the basic info readily available on using the print.css. It's fairly easy to override font colors with black and set details to print or not but what this assignment needs is precise element placement and styling within the #page details.
The site already features Bootstrap and other linked .css pages though I've unlinked them to test the pages and am trying to isolate out anything that could also be interfering with print styling.
It appears that float isn't working in IE. Our list page content to print lays out in floated divs in Chrome but font styling and other divs aren't rendering as intended. Firefox isn't displaying any of the required print content but indicating page numbering appears to agree with Chrome that there are 56 pages of labels, (sorry if you can't see them?) My hope is that this document can serve as a repository for the tips tricks and limitations of media #print.
I'm experiencing the same problem. I need to print onto specific Avery labels at exact dimensions and although I can get it to work with Chrome (despite it ignoring some Print CSS styles) - it doesn't work in Firefox. Safari seems to be in it's own world also.
I think the only way I'm going to solve this is to generate PDF's that the user has to download and print (or print the PDF's from their browser).
Sucks, but haven't found any solutions for a "CSS Print Browser Reset".
I'm rewriting a web app that allowed users to submit snippets of html via a WYSIWYG editor. The web app was designed from the ground up to be IE-only and quirksmode-only. As a result the html submitted by users was designed with this in mind.
One data item, for example, includes the following html:
<span style="font-size:small">Element name here</span>
Which incorrectly renders as font-size:medium in quirksmode (the way the user designed it), but renders properly as font-size:small in all other browsers including IE in standards mode.
I'm forcing IE into standards mode but I still want the app to look the same to existing users, so I'm looking for a way to override the font-size keywords in modern browsers to mean what they do in quirksmode. In other words I want the modern browsers to incorrectly render the text as font-size:medium. I'll contain all current user-submitted html in containers with class "old-user-content" or something similar.
For now I'm willing to resort to severe hackery to get this done. Any advice?
Use a media query to do this:
#media {
.old-user-content { font-size: medium }
}