I would like to use the panel module (i.e. attach not only script but also html and CSS and not have the addon CSS and JavaScript potentially interact with that of the main page) but not have the restraints of the boxed look. It seems like this ought to be fairly simple, but the only way I see to do this is to use the low lying APIs which lack much of the simplicity, security and documentation of the high level apis.
Use one of the following:
Stylesheet Service
UserChrome.css
UserChrome.js
UserChrome.js Extension
Resource Aliases
Related
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
I have an application where I could customize HTML templates depending on requirement of client. It has a provision of including CSS style scripts when creating a template which would be injected at the end when generating the template. By this way, client/support person could dynamically generate variety of HTML templates.
But when I give this project for a security scan, all the CSS injections are detected as security vulnerabilities (XSS Injections). My Application itself designed based on the CSS injection as it is required to create dynamic HTML template without the involvement of a developer.
Is there a way to prevent XSS security flaws at the same time of achieving application's end result?
Please let me know if there is an alternative way of doing this.
Allowing untrusted CSS input is an XSS flaw as it could be used for redressing the UI. For example, a malicious user could make their text and content appear to be authoritative text coming from the website itself by dressing it with the same style and positioning.
See the Google Browser Security Handbook for more information.
There are also ways to get script to run via CSS:
The risk of JavaScript execution. As a little-known feature, some CSS
implementations permit JavaScript code to be embedded in stylesheets.
There are at least three ways to achieve this goal: by using the
expression(...) directive, which gives the ability to evaluate
arbitrary JavaScript statements and use their value as a CSS
parameter; by using the url('javascript:...') directive on properties
that support it; or by invoking browser-specific features such as the
-moz-binding mechanism of Firefox.
Script execution via -moz-binding is available on Firefox 2 and 3. The Google Browser Security Handbook doesn't appear to have been updated since Firefox 3. This post indicates this is now fixed so that the XML file has to be readable from your own domain. XBL doesn't seem to be possible in current versions of Firefox.
In Internet Explorer 10 and earlier HTML Components allow script execution in CSS.
You can mitigate the risk of untrusted content by implementing an HTML5 sandbox. Also consider implementing a Content Security Policy with sanitisation to prevent users from escaping from your CSS context in any way (I haven't seen your code, but I wonder if a user enters </style> as part of the CSS, whether it allows them to escape the style tag?).
I am using insert-CSS node module for adding styles to DOM, internally this adds the embedded approach.
so far my understanding is using external style sheets is best way to do it. But while using insert CSS, css added to the js bundle and dynamically css embedded to the . so this also looks as same using external CSS.. and css will be cached with js and there will be one file(js+css) we can avoid one http request for loading CSS ?
I feel this insert-css is better than traditional approach(external css) am i correct? please suggest me your thought on the same and add some docs to refer.
so my question is which is the best approach among using "insert-css npm" or "external css"
I didn't find useful info on this question and sharing my experience.
My personal recommendation is not to use "insert-css" modules for the simple projects like dealing with forms and minimal amount of components.
"insert-css" - as mentioned above, "insert-css" add the embedded styles, in the network, its passed as base64 format. Though it's less weight in the network, browser needs to convert the base64 format to css and adds the embedded css, this conversion process will happen allays in js side, I guess which will cause the performance issues
CDN integration seems to be a hot topic among Tridion crowd. But, somehow, available discussions mainly revolve around pushing content to/fro CDN. What i'm specifically interested is:
What will be the proper way of modifying/prefixing inline images outbound links to use CDN?
The simplest way to go would be to create some post-processing TBB, operating on Output item, and place it inside 'Default Finish Actions'. Though, doing this on CD side would seem to be more correct, ain't it so?
EDIT
Consider fancier case: what if not only I want to modify image paths, but wrap the whole image links into ASP.Net controls. Where do I do this?
EDIT 2
So far, implemented tag to ASP.Net control replacement via TBB. Went smooth, only needed to keep an eye on the following subtle matters:
Consider CSS inline styles (i.e.: background-image: url(..))
New TBB needs to be placed after any link-manipulating logic (e.g.: Extract Binaries from Html, Publish Bnaries in Package, Link Resolver)
The quickest and most robust implementation is probably with a simple string replacements (in contrast to regexp's or XML parsing)
To keep standard "Preview" logic intact, some condition is necessary to trigger the logic
If you decide to go with ASP.NET controls for your CDN-hosted images, you may consider these phases/steps:
write a TCDL tag (e.g. <tcdl:image id="..." path="...") on CM during rendering
write a TCDL TagHandler implementation that transforms the TCDL into an ASP.NET include during deployment
write the ASCX control to do the CDN lookup proper when the visitor requests the page
I'm not sure if both step 2 and 3 are needed. You might also simply write the CDN path during the deployment phase (step 2 above).
At the same time I'd expect you to upload (updated) images to the CDN using a deployer extension, so that it also happens during phase 2.
I am working on a Facebook iFrame application, and have a question about styling.
I want the application content to look like the rest of facebook. So the most obvious approach I could think of was to use a stylesheet provided by Facebook for application development that includes such styles. However I cannot seem to find anything about this on developers.facebook.com or any other site for that matter.
I have created some FBML application earlier, and these was able to use Facebook styles directly since the application content was rendrered within the facebook pages. But iframes does not inherit the stylesheet from the parent content (nor should they), so I was wondering how (or possibly if) this can be done.
I have found some posts/blogs that simply tells you to create an application stylesheet that mimics the Facebook look. But I don't think this is a very good idea, as this CSS must be updated every time anything changes on Facebook. It also seems that all facebook wiki pages regarding CSS (which I have used before) has been removed.
The reason I do not want to use FBML Canvas is that Facebook is in the process of deprecating this approach. They recommend new applications to be created using iframes.
http://developers.facebook.com/docs/reference/fbml/
I really hope anyone has any good ideas on this.
There is no official way. For some reason, FB shards their styles to a ridiculous degree. They also change the filename rather than appending a version parameter every time they make a change to prevent downstream caching. Here's an example of todays stylesheets:
http://static.ak.fbcdn.net/rsrc.php/y-/r/40PDtAkbl8D.css
http://b.static.ak.fbcdn.net/rsrc.php/yE/r/u7RMVVYiOcY.css
http://static.ak.fbcdn.net/rsrc.php/yT/r/P-HsvhlyVjJ.css
http://static.ak.fbcdn.net/rsrc.php/yT/r/CFyyRO05F0N.css
http://static.ak.fbcdn.net/rsrc.php/y0/r/k00rCIzSCMA.css
http://b.static.ak.fbcdn.net/rsrc.php/yv/r/BJI6bizfXHL.css
http://b.static.ak.fbcdn.net/rsrc.php/yD/r/rmbhh_xQwEk.css
http://b.static.ak.fbcdn.net/rsrc.php/yn/r/xlsrXFt9-vD.css
http://b.static.ak.fbcdn.net/rsrc.php/yN/r/Uuokrl6Xv3c.css
http://b.static.ak.fbcdn.net/rsrc.php/y0/r/klTGALEjWM8.css
http://b.static.ak.fbcdn.net/rsrc.php/yN/r/mlYhlJwnCdr.css
http://b.static.ak.fbcdn.net/rsrc.php/yT/r/uFI2FW2LitH.css
http://b.static.ak.fbcdn.net/rsrc.php/yh/r/5Bzj1255G1S.css
http://b.static.ak.fbcdn.net/rsrc.php/yp/r/5UteuBI1b8_.css
You can automate this process fairly easily using either PHP or .NET using existing solutions Minify and Combiner respectively.
A simpler method would be to use the Web Developer toolbar for Firefox, go to Facebook and choose the Web Developer toolbar option to "view CSS" which will bunch all the CSS up for you. Copy and paste it into your own local stylesheet and you only have to update when Facebook makes a major change.
So while there is no simple way (that I am aware of), there are methods for you take care of it in a fairly speedy manner.