I was wondering if it is possible to provide a dedicated document editor to users (ie without the left hand sections such as 'Content', 'Settings', 'Media' etc) in certain circumstances just to make the editing process smoother.
For example, whilst viewing intranet site, they can click on an article and simply edit on screen without having all the umbraco furniture visible, just the document properties part, they then save and return to viewing the site (They would still need the full Umbraco layout for other activity).
Is this possible? A brute force option I suppose would be to iFrame Umbraco and use css to hide the left hand menu, but hoped there might be a more elegant solution.
Related
In one of our native iPad apps, there's a screen divided into a number of sections. For the most part, I think it works well with VoiceOver. But one of those sections is a UIWebView that displays web content related to the app, but provided by another vendor. It's essentially a black box to us. So I have no control over what that content is (or how accessible it is), it's incredibly dense with little nuggets of content, and it's on the left side of the screen, so it comes before a lot of the other content in (English) reading order.
As a consequence, if I ask VoiceOver to read through the contents of the screen, it quickly gets bogged down in this web content, and I can't imagine many people sticking it out to the remainder of the screen. But making them give up and scrub the screen to discover things seems obnoxious.
What I would love to be able to do would be to have the read-through treat that whole region as a single unit and use a summary label or heading, but still allow the user to point into it or toggle it somehow to allow interaction with the web content. Is there any way to accomplish this on iOS (without completely confusing the accessibility system)?
Of course, I'm sighted, so I'm also acting on speculation to some extent. Would the current UI be as confusing to users relying on VoiceOver as I think? Is what I'm describing as my solution going to be an even worse situation?
aria-hidden="true" would make a screen reader ignore the whole content (if this screen reader is modern enough to take into account WAI-ARIA. VoiceOver is).
That isn't what you're trying to achieve I guess, and most of the time it isn't desirable: why would screen reader users not able to read the same content as others, who are you to decide for them what they can/can't read that other people can't/can? Except in known cases of complete inaccessibility like a keyboard trap and this keyboard trap can't be fixed for now
a skip link before this content would allow SR users to jump to the content that is after this section.
if relevant, known ARIA landmark roles would allow to choose which part of the page they want to read (it would need this section to be the whole sidebar - complementary role - or the main one. Probably not the case)
SR can navigate through headings (as well as links and sequential reading and now landmark roles).
If this section and the next one begin with good headings, then it can be bypassed quickly.
Relevant WCAG 2.0 Techniques:
Providing heading elements at the beginning of each section of content (H69)
Providing descriptive headings (G130)
Using h1-h6 to identify headings (H42)
Organizing a page using headings (G141)
If there's no heading element and it can't be modified, but there's some text that could've been a relevant heading except it's a paragraph or item list or whatever, it could be marked as an equivalent with ARIA by using role="heading" and aria-level="N" (see role="heading")
if you've a good reason to modify the natural reading order of columns (I think this is the case here), you can modify layout with floats and flexible box layout (IE10+) (latter has had 3 different syntax throught the years, plugins like autoprefixer are welcome, or SASS/Compass...). Your left column would then appear last when tabbing but that requires modifying the layout of maybe a lot of templates.
aria-describedBy can probably be useful in some way but I've not enough knowledge about its uses, maybe somebody else will know more about it.
From comments Sixteen said:
Unfortunately, like I said, I don't have any control over that content at all. It comes from elsewhere, and is being displayed by our app
I agree with Felipe. I don't know what your code looks like, but say this in basic HTML. You probably either embed the code with an iframe, or inject the content into your code (example PHP include()).
Regardless on the method you use, you probably wrap a <div> around it. So you could do
<div aria-hidden="true">
//iframe/inject here
</div>
to make it not be seen by AT. Taking this basic model, we could pull out aria-hidden="true" and replace with role="complementary". You could put text in the div, push it off screen and say a nice line, and same for aria-described by, but you may want to tack on tabindex to it. Ex:
<div aria-describedby="ex" tabindex="-1">
<p id="ex" class="offscreen">Below is useless jargon by blah blah blah. It may
be more beneficial to jump to the main section instead.</p>
//iframe/inject here
</div>
My upcoming mobile web project requires viewing dynamically chosen pdf files inside the webpage. I am using iFrame to display the pdf file and the file can be scrolled using two-finger scrolling. But the problems I am facing are:
The first page of the file is not displayed completely on the iPad and gets cut off along the width unlike when I view it on the desktop browsers where the first page of the pdf is always entirely displayed although zoomed out to fit in the iFrame area.
There is no visual indication for the users that the pdf document can be scrolled, i.e., there is no scroll bar on the pdf document.
The controls (page navigation, zoom etc.) for the pdf viewer (Adobe reader) don't appear on the document unlike when I see it on the desktop browsers.
What is the best way to achieve what I am trying to do? Do any of you experts know any solutions/workarounds to the problems I am facing? An entirely different approach using anything other than iFrame can also be considered.
The reason why the pdf should be inside the html page is that, the list of pdf files will be on a menu bar on the left side of the page and the user can click on any of them to view on the same page. Ideally, they will have the capability to toggle between full screen view and that view.
Any help is appreciated.
I created a tiny JavaScript module that helps you to show a PDF inline and be able to scroll it. But I also couldn't figure out a way to make it fit the total width of the parent container.
Check it out: https://github.com/williamrjribeiro/ipdf-scroll
Cheers.
I came across this Recommended way to embed PDF in HTML? while researching on the web to find an answer.
The mentioned link discusses about some options that I can use and the google document viewer works for me though don't know if there is anything (like data limit) I need to be aware of before using it on the website. Also I have no idea if it is a good solution (though the full screen mode is not available, but zoom-in/zoom-out and next/prev page buttons are there are show up in the mobile safari on the iPad) to use for an web app that will be run on the iPad.
Anyway, I will keep researching for a better solution and if i don't find any, I'll stick to the google document viewer.
The issue appears to be a bug with Safari on the IPad.
I didn't find a solution for embedding the pdf in html but I did find this:
If you return FileStreamResult from your controller action instead of a view, the pdf will open in a new tab, it's not embedded html but at least your user is not having to download files and open them manually.
I had the same problem of the pdf not being displayed completely. The only thing I found to fix this was the change the size of the div containing the pdf.
For example if the element containing the pdf is a div then I change its width to any value and the rollback to the value it had before. Changing Width or height any one works.
Sometimes I had to wait a little using a setTimeout before calling my resizable method
jQuery mobile 1.2 alpha introduces Popups while it already has a similar widget, called Dialogs. They both seem very similar in nature.
What are the technical differences between Popups and Dialogs?
What Popups can do (any practical usecase as example preferred) that is impossible with Dialogs?
They are quite different beast. Here is my opinion based on my limited experience.
Dialogues
Dialogues take over the page, they contain a fullscreen dark background to make the "dialog" appear to have replaced the page.
Any page can be presented as a dialog by adding the data-rel="dialog" attribute to the page anchor link.
Like pages, you can specify any page transition you want on the dialog by adding the data-transition attribute to the link.
Can be chained.
Popups
Displays within the current page, and are probably more similar to the functionality commonly referred to as modals or lightboxes.
Can't be chained.
Popups are probably more suited for alerts, tooltips, small yes/no ok/cancel messages, making a thumbnail popup into a larger image, small ajax forms(newsletter, login, post a comment) etc. Useful when you don't want to overload the page with information, and only want to reveal certain functionality to users when they need or request it.
Dialogues on the other hand could be used in situations where you need to convey a lot of information (terms and conditions acceptance screen, etc), or when you really want to emphasis an alert, menu, the choice a user has, etc. Dialogues kind of break the flow of a page so should be used more cautiously.
One neat feature of the popups is that they can be used as overlay panels, which could be used to create a menu that slides in from the side of the screen, not too dissimilar to the menu in the Facebooks iphone application.
At the end of the day, either could be used, and neither is right or wrong, a lot of it comes down to personal preference, and how you want your application to flow.
One important difference is Popups appear in the same page as an element, where as dialogue is a different page in all and the background is blank.
I have a list of menu items and content in a single page. In PC browser or ipad, I want to see both parts in the same page. But in the smaller devices such as iphone and android phone, I want to separate the two so that you selects one of menu items in a page and see its content when he clicks it.
Jquery mobile demo page already does it. But I can't figure out how I can achieve it. Can someone explain or point to any good reference? Thanks
You may take a look at the following blog post which illustrates how you could organize your views so that based on the client type you could provide different contents.
The goal is to 'soften' hyperlinks off to external content slightly by displaying an external link bar at the top of the window, that displays above the content on the external website - containing a line of text that reads something along the lines of "The content you are viewing is not owned by this site, close this browser window to return to site name".
I know there's a way to achieve this using frames, but as far as I understand it frames are bad news for accessibility. Furthermore, if the user then accesses a site which itself has a frame set, there can be all sorts of fun and games!
Would welcome any feedback. Could something like this be achievable with jQuery perhaps?
No, you need to use frames. You need to have some degree of control, and the only way you can do that with remote addresses, is by keeping the user on your server, and showing the remote pages in a frame.
That being said, if the remote sites have a partnership with you, you could discuss a javascript option which displays a bar on the top of their pages whenever a specific cookie is set indicating the traffic came from your site initially.