I'm working on web application and our team wants to make it more accessible. In particular, we want to do a better support for people who can't see (using screen readers).
One of the popular solutions is NVDA. After reading their doc here, it's not clear - do they support a custom markdown?
Can I use some attributes/tags/metadata so that NVDA read stuff differently? For example:
Google will be read as 'Google'. Can I decorate it in some way, so that it will be read as 'Link to Google'?
Thank you.
There is no such thing as a custom mark-up for screen readers. Well, there is something like that, I'll tell you about it below.
Basically, when you try to make your web site more accessible (a very good thing to do, btw!), you should minimize your impact on screen reader users. By "impact" I mean that your goal should be that your blind user would see just the same thing as a sighted user, but as the web site developer, you give him/her this ability to see, navigate, open, click and so on, and so forth.
There is a way to customize the layout, though. It is called WAI-ARIA. You can do lots of crazy (and smart) stuff with it, it is great and mighty, but the first rule of the fight club, I mean, WAI-ARIA practices is:
If you can use a native HTML element 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.
— from here.
I.e.: If you can not to use ARIA, don't use it.
Let's take your example with the link to Google: you want your blind user to see the "Google" text and to understand that it is a link, right? Well, I'll tell you what you should do to achieve this. And you need to do... drum roll... nothing! NVDA, or JAWS (which you definitely should test with, it's a major player!), or TalkBack on Android, or VoiceOver on Apple devices, will say: "Link Google", or "Google link" (depends on the screen reader and on particular user's settings). that's all.
Of course you might have done this (but don't do it in any way!):
<span aria-hidden="true">Google</span>
See how crazy (and mighty!) it is? Thus you're telling the screen reader that you need your custom text to be read and hide your main link text (just in case; I've just tested with JAWS, everything works even without the aria-hidden attribute, so it's merely for an example).
However, if your link is a span with some fancy styling, ARIA is your everything: you just say <span role="link">, and your users will get a pleasant experience instead of trying to find which word to click.
And a last example: in Bootstrap there are lots of decorations like
<i class="fas fa-arrow-up"></i>
If they are on a link (and mostly they are), some screen readers such as JAWS would report two links, one with text, and one empty, just "link". In those cases it is really good to hide this stuff from screen readers:
<i class="fas fa-arrow-up" aria-hidden="true"></i>
NVDA, like JAWS, VoiceOver, Talkback, and several others, is a screen reader. A screen reader is software that a low-vision or no-vision user will use to access their computer. If you write semantically correct html, then your app will automatically work with a screen reader.
To create semantically correct html, the W3C has created a set of guidelines, call the Web Content Accessibility Guidelines (WCAG) that outlines things you can do to improve your web application to make it available for the greatest number of people.
It includes things like having alternate text for images, having labels for form elements, using well-worded text for links, and using the proper html tags for semantic elements, such as <h1> for headings, <ul> for lists, <table> for tables of data, etc.
When native html semantic elements can't be used, for whatever reason, then there are ARIA attributes and roles that can be applied to give screen reading software a clue as to what type of object you are trying to convey.
So, there is no markdown for NVDA or any other screen reader. You just have to be smart in your use of html.
Related
I am building a brand new website in Sitecore and I am looking for advice on the following scenario:
My site has 2 version of its homepage. Both are quite different. The layout is the same, but most of the components and sublayouts on it will change depending on whether the user is logged in or not.
Does anybody has a suggestion of a good practice, or way to do that in Sitecore? My basic requirements are, have a single URL for both (the website root, it is a homepage) and do not harm the content author experience.
My thought so far was:
Use of personalization to control the components to be displayed (Concerns: performance and the content author experience he woudnt have to change component by component to see both versions)
Use of two item in the tree and intercept a pipeline to resolve the right item at the right time (Concerns: the content author would have two home items to maintain *not actually a big problem)
Does anybody has any other approach or considerations on those I listed?
Thanks
An alternative solution would be to make use of devices, and use a pipeline to switch devices if the user is logged in.
Set up your Device in Sitecore to use the default layout as a fallback so it does not affect other pages in your site (and they continue to work as expected). You are then able to set different sublayouts and components for that Item (directly or in Standard Values for the template) for each device. You can make use the VaryByDevice caching option to make better use of the Cache.
Your content editors can also switch between the devices easily in the Page Editor from the ribbon. Any further customization you need in other areas of the site, such has switching out a single component, can be run using a Personlization Rule taking advantage of "where the current device compares to value".
It does sound like you have the need for personalization based on authenticated status, so I would recommend staying with the built-in personalization interface to avoid confusion. Authors will have been trained during Sitecore training on how to use personalization, and introducing an alternative method for accomplishing the same thing could lead to a less-than-optimal experience for the author.
To address your concern of the author needing to view components by toggling each one, I would recommend installing the Experience Explorer module. You can create presets that meet your rules on your presentation and then the author can preview the site for different 'experiences'.
If you have a single URL for the home page, it is more straight-forward to go with a single item, so I would definitely advise against having two home page items that are being resolved by the same URL.
You mentioned a concern for performance, so I would recommend you making sure that you enable your sublayout caching settings. In your case, varying by Data may be the way to go, given you would personalize with two sets of datasources.
In the past I have used the following crude technique:
Make two components, one for "logged in" and the other for anonymous.
Each rendering has just one line, a single placeholder, either:
<sc:placeholder key="logged-in" runat="server" />
or
<sc:placeholder key="anonymous" runat="server" />
For "logged in" I make a personalisation rule which hides the component if anonymous, and for the anonymous component I make a personalisation rule which hides the component if the user is logged in.
I then nest all the components under the correct placeholder key.
I'm having a hard time coming up with a solution for this problem.
I'm building a WYSIWYG designer, for micro sites. The templates for these microsites will be supplied by an intermediate user, and the end-user will manipulate these templates. So, there are really two groups of users of the app: template-buiders, and end-users. Think MailChimp.
This means my Ember app will start off with a template from a template-builder, say
<h1>An awesome product</h1>
<h2 contenteditable="true">Subtitle away</h2>
<p>{{#if optionA}} One thing {{else}} Another thing {{/if}}<p>
and the end user, having chosen this template, will then be able to customize it. There are a few requirements:
There will be static, uneditable portions of the page (h1 above)
There will be static, editable portions of the page (h2 above)
There will be options that affect the layout, style, etc. (p above)
So far, my attempts have lead me to build a handlebars helper that takes a string and a context, and returns a rendered template. This is because the above template will actually be coming over from a database, as a string - remember, it's user-generated.
That means, in my application's template, it would look like
<div class="preview">
{{preview-userTemplate template context}}}
</div>
where
template: '<h1>An awesome product</h1><h2 contenteditable="true">Subtitle away</h2><p>{{#if optionA}} One thing {{else}} Another thing {{/if}}<p>',
context: {optionA: true}
Now, this actually works, in the sense that it will update if context is updated, so I can add controls along the sides for the end-user to manipulate those options. So I have those (more of less) under control.
It's the WYSIWYG content editing that is giving me trouble. In the above template (from my template-builder users), I want them to be able to add contenteditable="true" to places in their templates where the end-users can change the content.
Now, these changes need to be saved. Ideally, I would be able to retrieve the instance view's template back from the DOM, after the inline edits have been made. Is this possible? The original {{data}} placeholder would need to be preserved.
Alternatively, I could make a view/component, so the template-builder would do something like this:
<h1>An awesome product</h1>
{{#editable}}
<h2>Subtitle away</h2>
{{/editable}}
<p>{{#if optionA}} One thing {{else}} Another thing {{/if}}<p>
but this seems like it would require a good deal of finagling to get the edits to stick - I'm not even sure right now how I'd go about it.
What do you guys think? Is there an easier solution that I'm overlooking? Thanks for any pointers!
Looks like an issue was closed related to the question I'm about to ask, so I wonder if I'm going to be skating on thin ice, but here goes. I feel like even though this is kind of localized by nature, it could be a useful example for other developers dealing with the Like button.
I seem to be having issues regarding the Facebook like button. The infuriating part is that I'm pretty confident I have everything setup properly, and even though the linter says "hey, this all looks kosher!" the like button fails to get the correct content and uses cached info from a different page.
Here's the case: referlocal.com. We serve daily deals, and list them right off the homepage. There can be one of many deals listed on that homepage, so obviously Facebook is seeing just one when it goes to take a peek at the root directory. Now, on the homepage, whatever deal your viewing has a FB Like XFBML tag with href and ref attributes set. Every page that displays a deal also has OG tags pointing directly to the offer view page. Deals can also be viewed on user pages. So, on these three paths:
/
/{username}
/offers/{city}/{title-url-alias}
a like button is included as well as OG tags that point to /offers/{city}/{title-url-alias}. For about 3 weeks, the button worked like a champ. But recently, it's been performing strangely. For any deal, regardless of the 3 locations, it always uses the information cached from the previous days "/" deal. Regardless of the OG tags or origination.
Here's the wildly confusing part. The Facebook Linter is supposed to recache the information on the page, right? Well, it sort of does. It picks up on all of the appropriate information set in the OG tags, but when you click the Like button at the bottom of the page, no dice, still uses the deal FB saw on the homepage from the day before.
I know this is probably killing my argument for localization, but check this out:
http://developers.facebook.com/tools/lint/?url=http%3A%2F%2Freferlocal.com%2Foffers%2Fdallas%2Fget-20-of-authentic-italian-american-cuisine-for-only-10-at-leggios-italian-ristorante-dallas
Regardless of the fact that the linter finds all the appropriate information, the like button at the bottom still is liking a deal FB cached from the previous day.
Any ideas?
I had this problem too. The linter caches things in a very weird manner - seems like the best thing to do is either to add a query string and change it every time, or just rename the file every time you're checking.
Wanting to check if I missed a setting somewhere, or if I'm just using the product in an unintended fashion.
I've created a prototype based on an existing site, and am using states to mimic functionality, along with tabcontrols and the like. When the end-user is marking up the page, and then changes tabs, or clicks a button to change states (but stay on the same 'screen'), the drawings from the end-user remain in the same spot. The issue is that if the user highlighted or crossed something out, it interferes with the new state.
Is this intended, an undocumented feature, or am I just expecting a little too much? This may be a dealbreaker for us using this tool in our organization if we can't either resolve or have a reasonable workaround. I'm open for suggestions.
I believe feedback is stored at the 'screen' level not the 'state' level
I suppose you have 3 choices:
Instruct your users to list the steps they did before they add their feedback
Change your states to different screens instead (they can still look like the same screen for the end user, but in your application they will be different screens)
Have your user submit screen shots instead of just .feedback files
The second option will allow you to organize your feedback better.
In short I think you're expecting more than they offer ;)
This link describes an exploit into my app using fckEditor:
http://knitinr.blogspot.com/2008/07/script-exploit-via-fckeditor.html
How do I make my app secure while still using fckEditor? Is it an fckEditor configuration? Is it some processing I'm supposed to do server-side after I grab the text from fckEditor?
It's a puzzle because fckEditor USES html tags for its formatting, so I can't just HTML encode when I display back the text.
Sanitize html server-side, no other choice. For PHP it would be HTML Purifier, for .NET I don't know. It's tricky to sanitize HTML - it's not sufficient to strip script tags, you also have to watch out for on* event handlers and even more, thanks to stupidities of IE for example.
Also with custom html and css it's easy to hijack look and layout of your site - using overlay (absolutely positioned) which covers all screen etc. Be prepared for that.
The bug is not actually FCKeditors fault. As long as you let users edit HTML that will be displayed on your web site they will always have to possibility to do harm unless you check the data before you output it.
Some people use HTMLencoding to do this, but that will destroy all the formatting done by FCKeditor, not what you want.
Maybe you can use the Microsoft Anti-Cross Site Scripting Library. Samples on MSDN
Is it some processing I'm supposed to do server-side after I grab the text from fckEditor?
Precisely. StackOverflow had some early issues related to this as well. The easiest way to solve it is to use an HTML library to parse user's input, and then escape any tags you don't want in the output. Do this as a post-processing step when printing to the page -- the data in the database should be the exact same as what the user typed in.
For example, if the user enters <b><script>evil here</script></b>, your code would translate it to <b><script>evil here</script></b> before rendering the page.
And do not use regular expressions for solving this, that's just an invitation for somebody clever to break it again.
FCKEditor can be configured to use only a few tags. You will need to encode everything except for those few tags.
Those tags are: <strong> <em> <u> <ol> <ul> <li> <p> <blockquote> <font> <span>.
The font tag only should have face and size attributes.
The span tag should only have a class attribute.
No other attributes should be allowed for these tags.
I understand the DONTS. I'm lacking a DO.
Is use of FCKEditor a requirement, or can you use a different editor/markup language? I advise using Markdown and WMD Editor, the same language used by StackOverflow. The Markdown library for .NET should have an option to escape all HTML tags -- be sure to turn it on.
XSS is a tricky thing. I suggest some reading:
Is HTML a Humane Markup Language?
Safe HTML and XSS
Anyway, my summary is when it comes down to it, you have to only allow in strictly accepted items; you can't reject known exploit vectors because or you'll always be behind the eternal struggle.
I think the issue raised by some is not that Fckeditor only encodes a few tags. This is a naive assumption that an evil user will use the Fckeditor to write his malice. The tools that allow manual changing of input are legion.
I treat all user data as tainted; and use Markdown to convert text to HTML. It sanitizes any HTML found in the text, which reduces malice.