I feel confused, as these 2 seems describe the same thing?
Level A − WCAG 2.0 Success Criterion 1.3.2 − Meaningful Sequence
If the content needs to be read in a certain order to make sense, ensure the webpage is written/coded in a way which indicates this order.
Level A − WCAG 2.0 Success Criterion 2.4.3 − Focus Order
When writing the HTML code for a webpage, make sure the content is coded in a logical order. It will then be communicated in a logical manner when read by screen readers. This is particularly important for web forms.
2.4.3 has to do with the tabbing order as you use tab to navigate through the page. It applies to interactive elements.
If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
(Emphasis mine)
1.3.2 applies to the entire page - all interactive elements and text. A screen reader user can navigate the entire DOM (*) using the up/down arrow keys. The order of the DOM is the order the screen reader user will hear the elements. If you use CSS to move elements around, say displaying an element at the bottom of the page even though it's near the top of the DOM, and if moving that element to the bottom of the page affects the meaning, then 1.3.2 would apply.
(*) It's not really the DOM they're navigating, it's the accessibility tree. You can "hide" elements in your DOM (eg, with aria-hidden) that prevent the element from appearing on the accessibility tree, but for conceptual purposes, you can think of the accessibility tree as a parallel structure to the DOM.
Related
I am maintaining a site for a client. The site has a high contrast toggle that sets appropriate contrast to meet WCAG 2.0 AA. However, without the user toggling that button, the site does not pass WCAG 2.0 AA (which is the goal). Once the user toggles the button, it seems to be WCAG 2.0 compliant.
The previous site developer said that it is fine as long as the user is able to switch to high contrast.
Questions:
[1] Does having a high contrast toggle (small icon in the upper left) make the site WCAG 2.0 AA compliant? Or does the default site need to be compliant before making the user hit a special button?
[2] Is there a universally recognized icon/location that gives a visual cue to switch a site to high contrast mode?
Short answer, yes, a high contrast toggle button is sufficient to pass WCAG but is not the greatest user experience. There are also some caveats in doing so as mentioned in "G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast"
The link or control on the original page must itself meet the contrast requirement of the desired SC. (If the user cannot see the control they may not be able to use it to go to the new page.)
The new page must contain all the same information and functionality as the original page.
The new page must conform to all of the SC for the desired level of conformance. (i.e., the new page cannot just have the desired level of contrast but otherwise not conform).
It's always best to have your main page satisfy minimum contrast requirements (WCAG 1.4.3) rather than creating a separate page, and possibly a separate user experience, that conforms to WCAG. If you go this route, hopefully you're just applying a different CSS to the main page so that you don't have to worry about maintaining a separate high contrast page.
I believe this resource from the WCAG answers most of your questions: https://www.w3.org/TR/WCAG20-TECHS/G174.html
In short: Yes, a button with the described functionality is sufficient to meet AA compliance, if:
All other AA success criteria is also met, when in this High contrast Mode (we don’t want to break some accessibility functionality in High Contrast Mode)
The button itself must be of high contrast and visible when entering the site
When enabling High Contrast Mode, all existing content and functionality must still be present on the page
You should also aim for having a label for the button, stating what it does. If nothing else, then as a tooltip that can also be invoked with keyboard. (Using the title attribute to create a tooltip is not sufficient.) This is because not everyone will understand its purpose from a simple icon.
I have a responsive layout that must be accessible for screen readers. The issue is around the order of buttons on desktop vs mobile.
On desktop the button order is
Cancel - Remind Me Later - Learn More
...and the screen reader reads left to right. However on mobile the button order is vertically stacked and is ordered as the reverse of the desktop:
Learn more
Remind me later
Cancel
The problem is the screen reader still reads as if user was in desktop mode - the visual order no longer matches.
Is there a way for the screen reader to change the reading order depending on the viewport?
In general, screen reading software ignores CSS (*). The order of your DOM is the order the screen reader will read it. Even if you used tabindex, that will only control the order of tabbing through the interface. If you use CSS to reposition elements, whether through flexbox or grid or float, the screen reading software will ignore that.
A screen reader user can simply walk the DOM (**) by using the up/down arrow keys. (** The user is not really walking the DOM but rather the accessibility tree, but it's similar to the DOM. Not every element in the DOM will be on the accessibility tree, but it's a similar analogy).
So, the only way to "control" the order that a screen reader hears the elements is by modifying the order of the elements in your DOM.
(*) (If you have a :before or :after pseudo-element with a content property, that property will be read by a screen reader as noted in step 2F of the "Accessible Name and Description Computation")
This is a common issue and there are a few solutions you can do. Without knowing much about your codebase, here are a few suggestions for you:
Not knowing how complex your markup is, you could provide a version of the form elements that are only visible on small screens. That way you can explicitly control the accessibility tree structure.
Another option, you can use CSS (flexbox or grid) to reposition the buttons based your media query for small screens.
While this would work, I would not advice using "tabindex="1", "2", "3" "..." to control tab order seeing as how your UI is not rendering in the correct order anyway.
Hope this helps. Good luck with your project.
Is there a way for the screen reader to change the reading order depending on the viewport?
One solution is to have two sets of the same menu and use your media queries to use one or the other
<div class="desktop">Cancel - Remind Me Later - Learn More</div>
<div class="mobile">
Learn more
Remind me later
Cancel
</div>
CSS:
.mobile {display:none}
#media screen and (max-width: 600px) {
.desktop {display:none}
.mobile {display:block}
}
This way, you will be free to let the DOM order match the visual order.
I work for a newspaper and we got a call from someone who uses Mac VoiceOver. He said beginning a few days ago VoiceOver no longer reads the articles on our site correctly. I've tested it with my extremely limited VoiceOver understanding and I can't get it to read the body of the story at all. It might read the lede but it just stops after that.
So is there a way to place a higher VO priority in the HTML? There are so many other elements on the page that are being read before VO even gets to the body of the article.
Here is an example page if it will help anyone figure out why it isn't reading the main body:
http://www.thebrunswicknews.com/news/national_news/professor-historic-outhouses-underappreciated-in-southwest/article_a4319478-fe98-5dd1-9c98-ebabde4ee856.html
It looks like TabIndex is used on this page. This is creating a navigation trap. For example, in the form with the heading "Welcome to the Discussion" there are two input fields with tab index of 100, and 101 respectively. This suggests to me that there are at least 99 other controls with tab index on them. This in itself is an accessibility violation, as the focus order, vs the content order is out of sync, and doesn't make sense. TabIndex (except a tab index of 0) should be used very cautiously, especially when it comes to accessibility!
Now, usually, we would be able to rely on VoiceOver arrow key navigation, to navigate to content elements, rather than active focusable controls, with tabbed navigation. HOWEVER, most of these tab indexed controls are within form elements, and so a different navigation mode takes over, and disables your typical arrow key, VoiceOver navigation. As such, users cannot (without a pretty deep knowledge of how to use VoiceOver/the weird structure of this page) escape from this. As such, what you have is a large keyboard trap, bouncing around approximately 101 different elements on your page. Set all tab index values to 0, or simply remove them, unless they're on elements that aren't usually focusable, and you should be good to go! Or at the very least, the issue that you're talking about will be fixed. There are a lot of other accessibility issues on this page, but fixing this is a good start.
what does Recalculate Layout Paint mean in chrome developer tool TimeLine records? and how to improve the page performance by reduce the page Recalculate,Layout and Paint's count? can give some suggestion?thanks
Basically, they're your browser figuring out how to draw the changes that you made to the page.
Don't worry about getting rid of them -- if you did that, your site would be static.
However... ...if you want to do something that IS useful for performance, which does have to do with reflows and repaints, then batch your changes together.
Lets say that you got a job at Twitter.
And your job is to write the next version of the window that adds each twitter post to the screen.
If a user gets 250 new tweets in their timeline, and you add each one in a loop, one after the other, the browser is going to slow way down, because every time you add one, it will have to reflow (move things around to make space for the thing you added) and repaint (style everything that was affected by the addition).
A better way of doing it would be to build the list of new tweets together off-DOM (ie: with elements that aren't actually on the page right now), and then add them all at once.
This cuts down on the number of times that a browser has to figure out where everything needs to go.
#Fabricio -- Micro-optimizing might not be great, but appending hundreds of browser elements in a loop, versus putting all of them in at the same time can make a big difference.
Just ask the Twitter guys, who weren't bothering to cache their jQuery objects.
Here's a very handy list of properties and methods that trigger the layout (reflow) of a page:
http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html
You want to minimize these calls as much as possible -- especially in situations where performance is critical, such as during the scroll event, or when animating large blocks of content.
You can use the "Profiles" tab and "Audits" tab to detect the performance of your code. The will give you a report about your codes.
You can reduce the page Recalculate,Layout and Paint's count by many ways.
Append many child at one time.
Hide elements before change them.
Give images and other elements height and width.
I've found many answers, here or inside MS' UI guidelines, regarding button positioning, but none about how to position (in which order) buttons when you have three actions to do, New, Edit and Delete.
I have a simple UI, in the upper part I placed a grid listing some data. Beneath, these three buttons. Following what I see around, I have to place them in this order:
New - Edit - Delete
But it seems to me that the delete button is more prevalent and easier to reach and click than the others (it falls on the lower-right corner of my window).
Any suggestion?
I think the order you cite (New - Edit - Delete) is most common because you would logically tab order from left to right when using the keyboard. New would arguably be the most used button (possibly edit depending on the application, but rarely delete) and therefore you wold want the fewest tabs to get to the New button.
Column layouts are always good for these kind of buttons, as one has to move the cursor into the button area, which is horizontally slight and therefore less likely to be accidentally clicked.
Also it provides a perceived division from the main GUI widgets, instead of spanning their length, which tends to create less of a perceived division in the user's mind.
But if you do not wish to change the overall layout, I would say that your current layout is good. Maybe add a delete confirmation box if one is not already present.