I'm reading through the epub3 spec and trying to get a handle on what media queries can be used for in combination with fixed layout documents.
I'd like to be able to create fixed layout pages with <meta name="viewport" specified for specific devices and select which device-specific pages are actually included in the reading order and ToC based on the device's screen dimensions.
The best route towards this seems to be to use the 'hidden' attribute on the <li>element in the nav xhtml, but this can't be altered by css as far as I can see.
I've also tried css visibility and display attributes, but these are clearly designed to change current rendering, not add or remove actual rendering-independant content - whereas the epub3 spec (as well as the html spec) suggests that hidden is intended for exactly the kind of thing I want to do.
Otherwise, any ideas on showing a different fixed layout page based on device screen dimensions would be gratefully received!
What you're looking for is the concept of "rendition mapping", rather than media query. It's the ability to select entirely different renditions (layouts, including reading order) based on device characteristics (among other criteria) within the same publication.
It's not in the current EPUB 3.0 specification, but it's chartered to be a future addition. See the rendition mapping charter, specifically the section on Rendition Selection and Mapping.
It seems like what you are trying to do somehow violates the notion of fixed layout, which assumes a specific screen geography. As far as I can see, you are going to need to create different books for different device sizes.
You could do media queries for screen dimensions, but there is no way to use these to control what is present in the spine to my knowledge. As you've correctly intuited, the CSS visibility property is about hiding HTML elements on a page, not spine elements. The hidden attribute in the TOC cannot be controlled via CSS.
You could try
#media (max-device-width: 640px) {
body.omit-if-narrow { display: none; }
}
but I'm pretty sure that would give you a blank page.
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>
I'm setting up a Wordpress blog with both Facebook and native Wordpress comments: http://lucky-stars.ca/yum/hello-world. I'm trying to get the formatting of the Wordpress comments as close as possible to the Facebook ones. I'm almost there, but I've run into a strange problem.
On any first-level comment that wraps to display on multiple lines, it does not use the text size I've specified on the comment and comment author when viewed in iOS with a viewport size between 768px and 480px. Any comment that fits on one line (or has manual breaks that fit on one line) is fine, and when I look at it on my iPhone in portait orientation (<480px), the problem goes away.
This problem also appears underneath the comment form where it says "your email address will not be published..."
My font size specifications are on the div that contains all of my comments, #comments.
This is what I've tried so far:
Clearing my cache.
Adding !important to the font rule on #comments.
Tried both ems and pixels for the font size.
Adding the size specification to the specific problematic divs (.comment-author and .comment-content).
Breaking down my font specifications into individual rules instead of shorthand.
Checked that there are no font rules that would be overriding this under #media screen and (max-width: 768px).
Adding zoom:1 to the #comments after I saw that Facebook's comments did this. This fixed the problem when I was using Chrome's User Agent and Device Metrics Overrides, but the problem persists on my iPhone.
I've tried googling the problem, but I'm not really sure what I'm looking for here since it's only a problem when the text wraps. And not just on text that wraps, but on the author's name as well, even though it's a separate div.
Any direction would be appreciated, I'm completely at a loss.
Adding this to my CSS fixed the problem:
html {
-ms-text-size-adjust: 100%;
-webkit-text-size-adjust: 100%;
}
Got this from https://github.com/necolas/normalize.css/blob/v2.1.2/normalize.css
I am relatively new to coding, html etc, and have only really written two websites before this. I am a graphic designer by profession and I am attempting a website provided by a client. I am still working on it but have come across a problem I just cant fix...
The footer appears to be different on every page, It is perfect on the home page, and seems to be ok on the about (apart from the gap underneath :/) but I cant sort it out on the testimonials or the contact.
Any help would be much appreciated
The site its currently on is: http://www.eplsdesign.com/grow/index.php
Thanks
Firstly, you are using <font> and <b> tags in the HTML. Nowadays, all styles (font, color, font-weight etc.) should always be specified via CSS. This makes the HTML much cleaner and easier to maintain.
Your pages look different because each page has a slightly different structure. On the Home page, the footer div is nested at the same level as your main content div. But on the Testimonials page, the footer is actually inside content. You need to be consistent with your page structure to achieve a consistent look. Getting rid of the <font> and <b> tags will help you do this.
I'd suggest you read up on basic HTML and CSS before continuing.
Throughout the jQuery Mobile docs, they use a left-side menu for navigation that changes to a more mobile friendly version when the browser width is smaller. You can see an example on this page.
They use this layout throughout the docs, and I can see in the source that they use two divs with the IDs "content-primary" and "content-secondary." My question relates to the fact that I can't find anything about this structure actually discussed in the documentation. It seems very strange that they would not include such a useful widget in the Framework. Did they use custom code to make this, or did I miss it in the documentation somehow?
I'm frankly quite surprised to see how challenging it's been to find a left nav example that works consistently and as expected in JQM.
I wound up copying code directly from the JQM docs, including grabbing their custom .js and .css scripts (which defines the .content-primary and .content-secondary classes, as well as the various #media queries which make the menu responsive).
The JQM docs do not use the "multi-page" format. Instead, each nav menu item links to a wholly separate URL (presumably prefetched into the DOM by adding data-prefetch="true" to the link), so each new page/URL must redefine the same nav menu over again.
This immediately makes my developer brain think "let's abstract the menu and include it on each page automatically". But how to 'include' the menu on each page without PHP (or other server-side language)? This is the problem I have yet to solve.
You may be able to call the $(document).bind('pageinit', function to manually inject your menu into the loading page by using javascript/jquery, but I have yet to figure out how to do this properly.
I'll keep you posted if/when I have a workable solution.
Actually this is not specific to jquery mobile, this is CSS3. You can check documentation here: http://www.css3.info/preview/media-queries/. Essentially what they do is specify style rules for different screen width using media query as shown in this example:
#media all and (min-width: 650px) { // you can define your width here
// style rules here
}
Are you talking about something like the left menu at http://jquerymobile.com/demos/1.3.0-beta.1/docs/demos/panels/panel-nav-form.html# ? Haven't played with it but it looks like these days it just takes
<div data-role="panel" data-position="left" data-position-fixed="false" data-display="reveal">
I'm aware of how to make invisible elements keyboard focusable and read by screenreaders, however for the purpose of a student-led survey - I would like certain elements to be invisible to screenreaders / keyboard focus to be less distracting, but have them visible for tutors to use using a mouse.
I've tried using iframes, however the keyboard can still 'tab' into them. I was considering a pop-up window that can control the parent window? - but might have some issues with blockers etc.
Many thanks! Mike
One of the simplest ways to get content ignored by a screen reader is to place it into an image and then set the alt text on the image to be "" in your HTML. This will cause the screen reader to skip this content since it can't interpret it. This will also eliminate any tabbing or keyboard focus since the web browser will treat it like any other image in your page.
Another way to do this, and a bit more complicated, is to detect if your page is being pulled into a screen reading browser and set the CSS properties of the content you don't want read by the reader to be have the following:
visibility: hidden; display:none;
Screen readers will ignore anything that is invisible and/or not displaying, thus it will not be read to the user. This is also a bit cleaner since you're not destroying the SEO ranking of the page but are just modifying the content displayed to users who don't need to see/hear it.
a good way to prevent screen readers from viewing an element is to apply the aria-hidden="true" attribute; this is fairly well supported by browsers, and will prompt JAWS and other screen readers to skip the content. You can also use role="presentation" - there's a good article on this here: http://john.foliot.ca/aria-hidden/
Applying tabindex=-1 will only only allow the element to be focused on by scripts and not keyboard input, so this will work too. Additionally, although I don't recommend it, I found while tearing my hair out over someone else's script, that if you don't have an 'href' attribute defined for a link element, (making it invalid) this also prevents focus.