Trying to make our SharePoint site WCAG compliant. I have added WAI-ARIA landmarks to the real content, but it is not passing because not all content is included.
When using HTML5 or WAI-ARIA landmarks it is best practice to include
all content on the page in landmarks. In this way users of assistive
technologies can use the landmarks for navigating the page without
losing track of content.
Make sure that all content on the page is included in HTML5 or
WAI-ARIA landmarks.
The issue is that the things that are coming back as errors are things I would not want to alert screen readers to like Googele Tag Manager:
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=XYZ" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
And random SP generated code like:
<div style="display:none" id="hidZone"><menu class="ms-hide"><ie:menuitem id="MSOMenu_Help" iconsrc="/_layouts/15/images/HelpIcon.gif" onmenuclick="MSOWebPartPage_S`enter code here`etNewWindowLocation(MenuWebPart.getAttribute('helpLink'),`enter code here`MenuWebPart.getAttribute('helpMode'))" text="Help" type="option" style="display:none"></ie:menuitem></menu></div>
Should I ignore these since it is not "real" content? Not sure what is the real best practice here.
1.3.1 Info and Relationships:
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
If you don’t present it (visually, auditory, …), you don’t have to care.
So your two examples, which seem not to be intended to be perceived by your users, are not affected by 1.3.1.
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.
some browser plugin, like readability can extract the 'article' from a webpage. Does anyone has idea about how to do it? What's the difference between the real articles and ads or comments?
Well, it depends how you want to define "real articles"...
Taking HTML5 into consideration, a webpage is constructed of semantic tags. Pages no longer have to be built with elements like <div> that have exactly no semantic meaning. In HTML5 you may use <section>, <article>, <header> and so on. Those elements can give an application pretty good sense of what is the main content of a webpage (e.g. print <article>s and skip <nav>s...)
Of course, not many pages use those tags yet. Furthermore, the tags might get abused and lose their meaning. In that case I'd stick to some statistics, e.g. selecting the largest elements in a HTML document. Moreover, if you have to scrape a webpage, you could use a modification of some pattern-matching algorithm, DIPRE for instance.
What if use just one html page with blocks inside,
like following
<div id="page1" style="display:block">...</div>
<div id="page2" style="display:none">...</div>
<div id="page3" style="display:none">...</div>
Active block has style="display:block" others "display:none",
when block becomes active "display:block" previous goes "display:none".
AJAX server communication, for instance
$.post("json", { "name": $("#name").val(), "sex": $("#sex").val() },
function(data) { console.log("server responded", data); });
What are disadvantages of this approach?
this is fast and dynamic but this approach lacks of no bookmarking facility, user can't save a particular link because the data is dynamic, also it is not search engine friendly, another disadvantage is history button back and forward will not work.
There are no disadvantages to using pure AJAX. In fact, in a lot of ways, its advantageous.
If you don't plan for it correctly you can have some issues. For example, you're used to having CSS effect 1 page at a time, but with pure AJAX, the CSS will affect every single page.
Also, all things become slightly harder. Linking to another page becomes harder, as you have to use JavaScript.
Lastly, your APP will now REQUIRE JavaScript, so I'd have a decent fallback.
This approach is used in some mobile Web frameworks, such as jQuery Mobile, and is intended to make a Web application feel more native. This is more Web 2.0 than traditional websites or web applications where each page transition involves a trip to the server.
I'm sure you know the advantages already, so let's move on to the disadvantages.
Slightly Greater Initial Latency:
The main disadvantage of this approach is that it will take slightly longer to load the page content due to the fact that you're getting all of the HTML from the server in one single trip. Thus, the initial load time may involve more latency than in a traditional Web 1.0 application. However, with just a few pages, in my experience, the latency is not significant enough for it to be a problem.
Loss of Back Button - More Complexity in Maintaining History:
Another potential disadvantage is that, as a developer, you'll need to approach the development of your site differently. Because you're transitioning pages by hiding one DIV block and unhiding another, you'll lose native back button functionality. This can be mitigated by using the hash in the URL to record the history of page transitions. You'd then need to register an event to watch the hash and reload old content as the user navigates backwards. You'd also need to change the state of JavaScript objects and variables to refect the old state, which may add complexity to your app. There are of course API's and libraries to make this easier to implement and help ensure that you write good, maintainable code.
More Stateful Scope Involves Rethinking Approach and Possible Learning Curve:
Lastly, you'll need to remember that the scope of each page doesn't reset after each transition. While this could actually be an advantage in that your app is more stateful, you'll need to untrain yourself in the way of thinking that each page loaded will cause all of the JavaScript variables and data you've set to be cleared out.
Summary:
My suggestion, if you're going to go this route, is to use a library. Don't reinvent the wheel unless you have a good reason to. Libraries, like jQuery mobile, help ensure that there is good fallback for older browsers, and some even make sure that your site will still load using Web 1.0 techniques for cases where JavaScript is disabled.
Can anyone recommend a Ruby library for creating a summary of a given URL? What I have in mind is the sort of one- or two-sentence summary as seen in search engine results.
You could you just scrape the web page for either description meta tag or if that's not available the first few sentences from the first <p> element on the page. The description meta tag looks like this:
<meta name="description" content="Nokogiri (鋸) is an HTML, XML, SAX, and Reader parser with XPath and CSS selector support." />
There's several Ruby libraries for parsing HTML. I hear that Nokogiri is good for this sort of stuff, but I have no experience with it personally.
Spidering a site and scraping pages is easy. Summarizing a page is difficult.
The metatags can help a little, as there is supposed to be a direct correlation between the summary and the content.
Unfortunately, not all pages have them, and many that do are inaccurate. That leaves us with having to scape text, hoping that it's pertinent to the content and context. Page layouts vary and there is no standard saying where on a page the main content actually lies and, because of CSS and Ajax, it might not be where we'd expect it, in the first couple lines of text. There might not be <p> tags, as a <div> or <span> with the appropriate CSS can replace the look.
I've written many spiders that did contextual analysis of the pages, trying to summarize, and it's ugly and not bullet-proof, especially when dealing with the English language because of homonyms, synonyms, and other "nyms" that get in the way.
If you can locate text to summarize, there are decent tools to reduce several paragraphs, or a paper, into a short sentence. Mac OS comes with a summarizer, and has for years. "Summarize Text Using Mac OSX Summarize Or Microsoft Word AutoSummarize" talks about enabling it if you want to experiment. "Mac 101: Shorten text using the Summarize Service" is about using it on the Mac. There's a driver or app for it that can be called from the CLI. See "How to use Mac OS X's Summary Service on the command line?" for more info.
And, as a demo, here's Lincoln's Gettysburg address summarized to one line:
It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth.
I am developing an issue tracking application in Django, mostly for a learning exercise but also for my own projects - and I am looking into using some AJAX for "enhanced" usability. For example, allowing users to "star" particular issues, which would add them to their watch list. This is implemented in a lot of sites, and is often AJAX - as the URL that the user is viewing doesn't need to change when they click the star.
Now, I am wondering what kind of response to return from my star_unstar view - that detects whether the request is being made via AJAX or not.
At present, if the request is an AJAX request, it returns just the section of HTML that is needed for the star, so I can replace the HTML in the star's parent DIV, so as the star appears "on" or "off", depending on the user's action.
However, I would much rather return some kind of JSON object, as it just seems more "proper", I think. The problem with this method is that the javascript would have to modify the star image's src attribute, the href on it, and the link title also, which seems a lot of work for such a simple feature. I am also looking into in-line commenting in the future, but I want to get a feel for how things "should" be done before I start coding lots of JS.
What is the general consensus when implementing features such as this, not just with Django, but all frameworks that operate in a similar way?
When I work with Ajax my main concern is usually to limit the amount of data I have to send. Ajax applications of this type should be very responsive (invisible if possible).
In the case of toggling a star, I would create the actual on/off states as CSS classes, StarOn and StarOff. The client will download both the off and on star when they first visit the page, which is acceptable considering that the star is a small image. When you want to change the star appearance in the future, you'll only be editing CSS, and won't have to touch the javascript at all.
As for the Ajax, I'd send back and forth one thing -- a JSON variable true/false that says whether or not the request was successful. As soon as the user clicks on the star, I'd change it to the StarOn state and send out the request. 99% of the time Ajax will return true and the user will not even realize that there was some sort of delay in the web request. In the rare case where you get a false back, you'll have to revert the star to StarOff and display an error message to the user.
I don't think your question relates particularly to Django or Python, as you point out at the end.
There's a lot of personal preference in whether you return a blob of HTML to write into the DOM or some serialized data as JSON. There are some practical factors you might want to take into account though.
Advantages of HTML:
- Easy and fast to write straight into the page.
Advantages of JSON:
- Not coupled to the front-end of your application. If you need that functionality anywhere else in the application, it is there ready to go.
My call on it. It's only a relatively trivial amount of HTML to update, and I'd probably go for returning JSON in this case and giving myself the extra flexibility that might be useful down the road.