I have a header tag that contains the title of the page. The Windows screen reader is not reading that text and i wanted to know if there is a way to do so by adding some aria items?
<section class="section">
<header class="section-title" ip-l10n="county_list">List of Countries</header>
</section>
Just to make sure we're talking about the same thing, there are headings and headers. Headings are <h1> through <h6> elements. Headers are typically used when describing tables and are the names at the top of the column, the column header or <th> tag.
You had mentioned that your header contained the "title of the page". The title of the page is normally contained in a heading, specifically an <h1> if it's the main title of the page. So I wasn't clear which term you were really asking about.
I know your example used the <header> element so I will limit my comments to just that element, but I did want to point out the aforementioned differences to make sure we're all talking about the same thing. Accessibility and aria tags are all about semantics so it's good to be clear about the semantics of your question.
The <header> element is a container for stuff that's usually at the top of your page. By default, it creates a banner landmark. A <header> usually contains a <nav> which is the main navigation for the site that is repeated on all pages. It might also contain the company logo as an image and serves as a link back to the home page. It might also have account info, or if a retail site, the shopping cart contents. So a <header> might have interactive and non-interactive things.
In your example code, you just have plain text in your header. That's not interactive so a screen reader user will not hear the text if they are using the tab key to navigate the site. They will hear the text if they navigate the DOM using the up/down arrow keys with the screen reader.
If instead, you really meant for your code to be a heading, and thus the <h1> tag, that is also static text that is not interactive so again, the screen reader user will not hear the text if they are using the tab key to navigate the site. However, they can hear the text if they use the screen reader H quicknav key (to navigate to a heading).
So if you want to clarify your question, I can update my answer.
Related
I've inherited a project that uses a lot of click-triggered JS to change page content instead of linking to different actual HTML pages. I'm being asked to make JAWS read the page title when this happens, as if a new page is being loaded.
From my observations and a bit of light testing, reading the page title (meaning the contents of the <title> tag) is standard behavior for JAWS when linking to a new, separate page (as in a foo.html file), but not what happens when a same-page link or button is clicked.
How can I cause JAWS to read a page's title after a link or button is clicked that changes the existing page's content in a way that seems like a new page to the user but is actually the same file under the hood?
For this question, please assume that refactoring what I have to use an actual new page instead of JS content replacement is not an option. And if something is wrong with my initial assumptions, please let me know that as well.
It sounds like you have a single page app (SPA). You can't force the <title> element itself to be read but if you also put the same text into an aria-live="polite" container (a visually hidden <div> or <span> (*)), it'll be read.
You still want to update the title, even if it's not read, because the screen reader user can use a shortcut key (INS+T with jaws) to read the page title. And when the user switches between the browser and another app and then back again, they'll hear the title, so it's still important to update the title.
There are some decent blogs regarding accessible SPAs:
Accessible page titles in a Single Page App talks specifically
about the page title in SPAs
Building Accessible Single Page
Apps talks about general principles but doesn't really have any
code examples
Single page applications, Angular.js and accessibility talks specifically about using angular but the concepts and code examples can be applied generically.
(*) Note, when visually hiding the aria-live region, don't use CSS display:none because that'll hide it from the screen reader too. Use a sr-only type class. See What is sr-only in Bootstrap 3?
There's good info in slugolicious's answer. The specific issue has a simpler solution, though: <title> elements can be ARIA-ified.
<title role="banner" aria-live="polite">Default title here</title>
in conjunction with
$(function() {
// existing logic here
$(title).html("New title here");
});
being called when the new content loads.
Several questions in one here but I suspect will all have the same answer.
Using the CKEditor in a CakePHP project where the content being edited is to make the html part of an email.
Most email applications don't fully support HTML net alone true HTML5.
An example of which is to center text in an email paragraph you use either <p align=center> or <center></center>
In the CKEditor when in source mode editing if do a <p align=center> and save it (or just toggle the source edit mode) it removes the align=center because in HTML5 that's no longer valid.
How can I allow this in the CKEditor?
Can I enable HTML4 validation instead of HTML5?
I also have a table in the template where half of it is edited in a field(textbox) called Header (the header of the email template) and another field called footer.
In the Header I want <table><tr><td>
In the Footer I want </td></tr></table>
Then my message content is placed in the TD cell between the header and footer.
However the CKEditor won't allow me to have an HTML TAG and not its closing TAG.
Any ideas on how to make this happen as well?
Regards
Ian
To change the HTML that it's accepted by CKEditor, adjust its ACF settings. The simplest way is to allow everything:
config.allowedContent = true;
That won't solve the halve tables part.
For that you can try to use config.protectedSource, defining a rule for both the opening and closing parts, but taking care to add also something there that allows you to target only that table and not any other table that might be in the content.
(Of course the best solution would be to but that table outside the editor when you create the mail with all the parts)
I want to allow authors to enter long descriptions in the CKEditor image plug-in dialog, descriptions which then are available to screen readers via the aria-describedby attribute. In our use case, authors work in a WYSIWYG mode; they're not expected to edit raw HTML, so we can't ask them to enter an ID in the image dialog, add a corresponding ID to some other element, etc.
It's a trivial matter to enhance the CKEditor image plug-in dialog to have a field where the author can enter a long description to accompany the short alt description. The result could be something like <img data-long-description="this is a long description" alt="short description" />. But what we need is <img aria-describedby="longDescriptionID" alt="short description" />, where longDescriptionID is the ID of some element on the page (hidden from sighted users or not)....
I have a couple of possibilities in mind. (1) keep the image plug-in doing what it does: output an <img /> tag, as in the first example, and then some other code in the end user-facing view has the responsibility to find data-long-descriptions, replace them with IDs (randomly generated, say) in an aria-describedby attribute, and somewhere in the view insert corresponding content hidden from visual users, so that screen readers will pick it up.
Possibility (2) is to have the image plug-in output something like <span class="accessibleImage"><img aria-describedby="randomID1" alt="short description" /><span id="randomID1" class="accessibleLongDescription">This is nice, long description of the image blah blah blah</span></span>, where .accessibleLongDescription is hidden except to screen readers.
It's good that you're looking into this. More detailed descriptions for images are often useful. A couple of thoughts...
It isn't just people who use screen readers that find longer descriptions useful. People with cognitive disabilities will often benefit from more detailed explanations of complex images. If you can make the descriptions available on demand to anyone, this will help more people.
When the description is inserted into the DOM it needs to be immediately after the image it relates to. Screen readers use a translation of the DOM known as the accessibility tree to access content, so DOM order is important.
So one possibility is to combine your methods - search/replace the data attribute as you suggest in your first method, then insert the description based on the pattern in your second method.
Another possibility might be to use a disclosure widget pattern instead. Represent the image as the trigger control for the disclosure, and make the detailed description available when the widget is expanded.
A reasonable disclosure widget pattern is here.
I've added the "html"-button to TinyMCE on an EZ Publish site so that the users can write custom html into the xmlblock-field. But html-code with div-, img- and other tags get stripped when the user saves. If I use the ''-tag I assume that the html-code inside will be rendered as viewable html-code on the web page, instead of actual html-content.
How can I enable html-editing in the ezoe?
This is what I'm trying:
Click the html-button in TinyMCE.
Write html-code:
<div style="text-align:left; width:496px; margin-left:auto; margin-right:auto;">
<img id="Image-Maps_fottoey" src="some url.jpg" width="496" height="249" alt="" />
</div>
Click "Publish". When viewing the page it has no trace of the html-code from step 2.
I've tried to add the following to my override content.ini.append.php:
[literal]
AvailableClasses[]
AvailableClasses[]=html
as per http://acidre.com/blog/ez-publish-saisir-du-contenu-directement-en-html/ but that doesn't help.
Update:
It works now with the changes that I made to content.ini.append.php. This change adds "html" as a literal option and gives you a new icon in the editor, which Nicolas pointed me to (looks like a sheet of paper and is on icon row 2, first section before the Omega-icon.
When you add the html-source in the purple edit field, the editor will create links if it discovers that you've pasted inn urls. These links are blue in the editor. You must break these links with the "Break link"-icon to the far right on icon row 1. There should be no blue hyperlinks in the editor when you save. If you've managed this, the published page should display your custom html nicely :)
The usual way of enabling literal HTML in eZ Online Editor (based on TinyMCE) in eZ Publish is to uncomment the
AvailableClasses[]=html
configuration directive in an override of content.ini. A bit more of information here : http://share.ez.no/forums/setup-design/custom-tag-stop-while-running/comment64177.
Then, the literal tag should be available to editors through the literal button in TinyMCE (this button looks like a text sheet). The dropdown proposed in the pop-up menu shows 'html'.
Allowing raw html requires a few editorial guidelines and full trust in editors, but i am sure you are aware of this.
Cheers,
Nicolas
I have a page that shows the main product for that page, next to it though are "related products" which when you click on them you go to their page, and they have their own related products as well. The problem is that the related products are getting indexed by Google so when you search for product-A you may get the product-B page where product-A is a related item, instead of just getting the product-A page. I am trying to prevent this. Any ideas?
Thanks!
You can add rel="nofollow" in any links you don't want a bot to crawl. In this case, you can apply that tag to all your links and google won't follow them off your main page.
http://en.wikipedia.org/wiki/Nofollow
EDIT for clarification:
Page "A" is for widgets. You want this page to be returned for searches regarding widgets; on this page is a "related searches" section which links to Other Widgets. On all the anchor tags on page "A" which link to pages "B" and "C" (the related searches for Other Widgets), you'll put a rel="nofollow" tag. This will prevent Google from hitting page A and then following your "related searches" links off to pages "B" and "C".
This will NOT prevent pages "B" and "C" from being indexed on their own, it just prevents them from getting pulled in from page "A".
EDIT#2:
rel="nofollow" tells bots you don't want them to follow the link to the second page. Regardless of the anchor text on a link from A->B, if you've nofollowed it the bot won't "flow" pagerank to the linked-to page and should not follow the link to page "B" to index it due to that tag on the anchor. Note that this is not foolproof: Yahoo and other SE's may not treat nofollow like Google....so your best bet is to make sure that each page is strongly on-page-SEO'd such that it gets included in the index for the term you want it to be included for. Hope this helps...but like much of the SEO world there are few hard-and-fast rules which apply universally.
yes... put them at the bottom of the page for content,
if you want that to appear visually at the top of the page, use a css layout to re-arrange the page elements
also, as darksquid already said, add rel="nofollow" to links you don't want considered
another tip (pertaining to your comment on darksquid's post):
You could load the content via ajax, which would keep most search engine spiders from seeing it at all (since they don't generally execute javascript)
Use Google Applicance - googleoff / googleon Tags:
http://www.geekzilla.co.uk/ViewC8614968-56ED-4729-9C12-F01677DAC412.htm