I am in the process of receiving training in a11y accessibility WCAG 2.0/2.1 standards, and I saw some testing recommendations involve testing the page with CSS turned off to ensure elements are rendered in an order friendly to screen readers.
Is there a way to configure an e2e test pass to turn off css styling for this purpose? Either within cypress or through some external configuration?
That recommendation is not actually a good idea and perhaps may be out-dated.
You see if you use something like flexbox and change the order of elements of the page using flex-direction: row-reverse (for example) your site would probably fail WCAG 2.4.3 Focus Order.
Now if you turned CSS off, you would not be aware of the problem (assuming your DOM order is correct).
DOM order is important for accessibility (especially as some browsers are text only), I am not saying it isn't, but what the end user actually has to interact with is more important.
As screen readers take their information from the accessibility tree the browser exposes (which is influenced by the CSS if it changes the order of DOM elements) you need to test with CSS turned on.
What should I do?
By all means turn CSS off, you can use something like Web Developer plugin for that.
It is a useful sanity check that you aren't reordering things with CSS to counteract the fact that your DOM order is incorrect.
However yet again if you look at raw DOM order you may find that you think something is in the wrong order, correct it and then miss the fact that it had it's order swapped by CSS.
For 99% of testing leave CSS turned on.
A better test is to look for any classes in your CSS that may change order (float: right, flex-direction: row-reverse etc.) Then identify elements that use those classes and just see if everything looks correct.
A great tool for testing your site tab / focus order is Accessibility Insights. This will often pick up incorrect ordering of the page, whether by CSS or by DOM order.
One of the tests is for "Tab Stops" and all you do is start the test and tab around the page.
It gives you a visual indication of what was focused, as well as numbers on each item so you can review them later (which is great for large teams when you need to highlight specific issues).
The test takes all of 2 minutes to perform manually, so far I have yet to see a good automated solution so manual checking is the way to go.
The best test
Forget automated tests, just fire up a screen reader and use the page.
Obviously you should only do this at key points in the development cycle but within 30 seconds you can find most errors once you get proficient with a screen reader. This is also really handy for picking up weird issues such as paragraphs reading in the wrong order.
Cover your screen, switch on your screen reader of choice and set yourself a task, e.g. "fill in the contact form".
It will give you waaaay more feedback than automated testing.
Related
Is it ok in regards to accessibility to scroll content into view? Is it disorienting for some users to have the page move by itself?
For instance, if a dropdown opens and only a few options are visible, is it better to let the user scroll the whole dropdown into view or to do this programmatically?
Scrolling into view seems like a nice UX improvement (we're avoiding an extra action from the user) but also possibly important accessibility-wise (the user might not realize there is important content below the fold, so we're making sure they see it).
On the other hand, moving the whole page seems like it could be jarring to some user, who may lose track of where they are on the page...
Good question. There may be some that benefit from it, but others will definitely find it disorientating.
Without knowing more about the actual case, I would default to not auto-scrolling, because auto-animation requires a number of other things to be in place.
There are some WCAG rules which only apply when there is automatic movement. (e.g. https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide)
Also the fact there's a CSS media query to accommodate this kind of thing shows that this is a feature that some users will prefer to avoid.
If you're using a CSS transition to handle this, it should be quite easy to put it in a prefers-reduced-motion media query, and the browser preferences would offer a mechanism to switch off the feature, making it compliant with SC 2.2.2
Even if you're doing the scrolling entirely with javaScript, you can still access the media query.
As an alternative, or even as an additional hint (belt and braces), you might consider adding a visual affordance to the last visible item indicating "more...". I have seen this handled with an ellipsis, or downward-pointing triangle/caret, but those idioms aren't strongly established for this kind of thing.
Screen reader users may be at a small advantage here. If you've marked up your popup correctly, the AT will announce the number of items, visible or not. :)
Good luck!
Many developers/accessibility experts suggest to disable CSS for checking the website for accessibility, but no one explicitly says how it may actually be helpful in terms of web accessibility.
So here I am, asking you exactly that, because all my attempts to check this in reliable (I WANT TO BELIEVE!) sources like "w3.org", including their WCAG 2.0 recommendations, don't say anything about making website accessible without CSS. Moreover, they say it may be "relied upon" some technology, like CSS, for example.
You no longer need to explicitly verify that pages are readable without CSS, but it can be useful as a technique for ensuring correct reading order.
The requirement to make pages readable without CSS is a carryover from the days when Section 508 was the dominant accessibility standard.
36 CFR Parts 1193 and 1194 - Published February 18, 2017
There is no direct analogy in the WCAG 2.0 Success Criteria for section 1194.22(d) of the existing 508 Standards, which states: “documents shall be organized so they are readable without requiring an associated style sheet.” 36 CFR §1194.22(d).
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/single-file-version
WCAG 2.0 addresses this same issue in a different way with Success Criterion 1.3.2 - Meaningful Sequence.
One of the techniques for meeting this criterion is making the DOM order match the visual order (C27), which is largely what this comes down to anyway.
I would say that a good reason to actually disable CSS in terms of checking accessibility is to see that your site structure is built up in a logical way.
On the other hand, a better way to test this is to use a screenreader and tab through the site using use tab / shift + tab with a keyboard. In that way you do not only get an eureka-moment on structural issues you also get the audio-feedback that will give you lots of AHA:s about phrasing, ARIA-issues and hidden elements not hidden in a accessible way.
I'd point you to try out ChromeVox
If you use the accessibility testing tool Wave you can actually disable styles in the tool. So, as built in a testing tool it's a great way to test the structural element flow. There is no purpose in itself to disable CSS besides testing accessibility in this way.
I'm experimenting with CSS Transitions these days. I'm trying to build an animated web page with solely CSS.
Everything works just fine, but I came across an organisation-related issue: My CSS file look like a mess! If the client asks me to delay a specific animation or changing the order of another - It takes me few moments to find the right line to do that (few moments = too much).
May I separate animation-command from pure-design-css? How should I design browsers prefixes CSS (one line or several)? Changing animation speed must be as easy as a click (but now I need to type it 5 times).
I'd be glad to hear some ideas about CSS Trnasitions code organisation.
Thank you!
CSS files should be organized regardless of their content (transition rules etc.), this contributes both to browser's parsing, and to the file's readability in general. Note that:
You should order your CSS according to the rules specification and the cascade (obviously), also aggregating duplicate rules wherever possible.
It is highly recommended to add a table of contents, see example in this article on CSS files organization.
You better order key-value pairs in a consistent manner (e.g. alphabetize them) as recommended at google's 'make the web faster' article on payload.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Even though I always strive for complete validation these days, I often wonder if it's a waste of time. If the code runs and it looks the same in all browsers (I use browsershots.org to verify) then do I need to take it any further or am I just being overly anal?
What level do you hold your code to when you create it for:
a) yourself
b) your clients
P.S. Jeff and company, why doesn't stack overflow validate? :)
EDIT: Some good insights, I think that since I've been so valid-obsessed for so long I program knowing what will cause problems and what won't so I'm in a better position than people who create a site first and then "go back and fix the validation problems"
I think I may post another question on stack overflow; "Do you validate as you go or do you finish and then go back and validate?" as that seems to be where this question is going
a) Must look the same
b) As standards-compliant as possible, but not so anal that it blocks finishing work
In a situation where you have perpetual access to the code, I don't think standards-compliance is all that important, since you can always make changes to the code if something breaks. If you don't have perpetual access (ie, you sign off on the code and it becomes someone else's responsibility), it's probably best to be as standards-compliant as possible to minimize maintenance headaches later... even if you never have to deal with the code again, your reputation persists and can be transmitted to other potential clients, and many teams like to blame the previous developer(s) for problems that come up.
I think this is an area in which you should strive to use the Robustness principle as far as is practical (which is good advice for any area of coding). Just because something works today doesn't mean it will work tomorrow: if you're relying on a particular HTML/CSS hack or even if you've just been a little lax in emitting strictly valid code, the next iteration of browsers could well break. Doing it once the right way minimises this problem (though does not entirely mitigate it).
There is a certain element of pragmatism to take here, though. I'd certainly do all I could for a client's site to be valid, but I would be willing to take more risks in my own space.
I think it's only "tech" guys that really care for "100% standard compliance". My usual page consumers (= users) don't care if there's no alt-attribute for a "menu border picture element".
I usually just make sure that I don't see any obvious errors (all tags closed, all lower case, attributes in quotes, ...), but if it looks good on IE and FF, that's all I care for. I don't really care if I use a non-standard attribute in any HTML tag, so that the page doesn't validate against an DTD - as long as I get the visual results that I intended to get.
For understanding why validation matters, it is needed to understand how a browser works at its different layers, and also a little bit about the history of web from the perspective of web browsers.
The HTML you give to a browser is interpreted by the browser following the DOM, an application programming interface that maps out the entire page as a hierarchy of nodes. Each part of that tree is a type of node containing different kinds of data. DOM (Document Object Model) was necessary because of the diversity of HTML pages that early web browsers (Netscape, IE...) implemented to allow alter the appearance and content of a web page without reloading it. For preserving the cross-platform nature of the web, W3C wanted to fix the different implementation of those browsers, proposing DOM.
DOM support became a huge priority for most web browsers vendors, and efforts have been ongoing to improve support on each release. So, it worked.
DOM is the very basic step with which a web browser starts. Its main flow is:
parsing HTML to construct the DOM tree
render tree construction
layout of the render tree
painting the render tree
The step 1 gives the content tree, with the tags turned to DOM nodes. The step 2 gives the render tree, containing styling information.
So, why validation matters: because content tree and render tree are the basis from which the web browser start its job. The most they are well defined, the better for the web browser.
Ultimately, the DOM is also the basis for your JavaScript events. So, its validation helps to the interaction layer too.
I know this isn't answering your whole question, but it is worth considering that by using completely valid html you can be sure that your website should work properly in future web browsers that haven't been released yet.
My approach tends to be to ensure I can completely validate on all pages, however I still send the page as text/html instead of application/xhtml+xml so there are no ugly XML errors in the event I have missed something.
For me, I feel like I've done a good job if my code validates. Seeing the green check box on the w3c pages just makes me slightly giddy. As for group b, They usually only care that it looks and works the same across browsers. They only place I've found that this is not true is the government sector. They require complete validation not only with the w3c but also passing ADA tests (basically how does it sound with a screen reader).
p.s. when I say government sector, I mean specifically the state of California and a few counties inside it. I have had no ther experience with other government groups besides them.
I think validation is a good litmus test of whether you've done things properly, so if there are only a few minor problems, why not fix them and ensure your site will at least be understood correctly by browsers in the future (even if they do render things differently for other reasons)?
OTOH, for most projects, validation seems like a huge headache and if you can get things working across browsers, it's not worth spending an extra day/week+ on just validation.
Except that the validators themselves are so positively anal,
when they flag an error or warning whenever a -moz- or -webkit or -o- i.e. a browser specific qualification term is used.
also they want you to specify 0px rather than 0 or other units
Zero is Zero whatever units the validator wants to check it against!
just try validating the WordPress twentyeleven style.css it throws 140 odd errors which are all of the nature above or the validator is recovering from parse errors
The validators are useless if you cannot sort the wheat from the chaff!!!
We need validators that recognise browser specific qualification terms!
Developing websites are time-consuming. To improve productivity, I would code a prototype to show to our clients. I don't worry about making the prototype comform to the standard. Most of the time, our clients would approve the prototype and give an unreasonable deadline. I usually end up using the prototype in production (hey, the prototype works. No need to make my job harder.)
I could refactor the code to output valid HTML. But is it worth the effort to output valid HTML?
It is only worth the effort if it gives you a practical benefit. Sticking to standards might make it easier to build a website that works across most browsers. Then again, if you're happy with how a website displays on the browsers you care about (maybe one, maybe all), then going through hoops to make it pass validation is a waste of time.
Also, the difference in SEO between an all-valid html website and a mostly-valid html website is negligible.
So always look for the practical benefit, there are some in some situations, but don't do it just for the sake of it.
Yes. It's hard enough trying to deal with how different browsers will render valid HTML, never mind trying to predict what they'll do with invalid code. Same goes for search engines - enough problems in the HTML may lead to the site not being indexed properly or at all.
I guess the real answer is "it depends on what is invalid about the HTML". If the invalid parts relate to accessibility issues, you might even find your customer has legal problems if they use the site on a commercial basis.
Probably not if you have a non-complying site to begin with and are short on time.
However, and you won't believe me because I didn't believe others to begin with, but it is easier to make a site compliant from the start - it saves you headaches in terms of browser compatibility, CSS behaviour and even JavaScript behavior and it is typically less markup to maintain.
Site compliance (at least to Transitional) is pretty easy.
Producing compliant HTML is similar to ensuring that you have no warnings during a compilation - the warnings are there for a reason, you may not realise what that reason is, but ignore the warnings and, before you know where you are, there as so many, you can't spot the one that's relevant to the problem that you're trying to fix.
If you use Firefox to view your web pages, you'll get a helpful green tick or red cross in the bottom right hand corner, quickly showin you whether you've complied or not. Clicking on a red cross will show you all of the places where you goofed.
Some of the warnings/errors may seem a bit pedantic, but fix them and you'll benefit in many ways.
Your page is much more likely to work with a wider range of browsers.
Accessibility compliance will be easier (You'll have 'alt' attributes on your images, for example)
If you choose XHTML as a standard, your markup will be more likely to be useful in an AJAX environment.
Failure to do this results in unpredictability.
One of the biggest problems with web browsers is that they have perpetuated bad habits (And still do, in some cases) by silently correcting certain markup problems, such as failure to close table cells and/or rows. This single fact has resulted in thousands of web pages that are not compliant but 'work', lulling their developers into a false sense of security.
When you consider how many things there are that can go wrong with a website, being lazy when it comes to compliance is just adding more problems to your workload.
EDIT: having read your original post again, I notice that you say you don't bother with compliance when working on a prototype, then you go on to say that you usually use the prototype in production - this means that it's not strictly a prototype, but a candidate.
The normal situation in such circumstances is that once the customer accepts a candidate, no time is allocated for bug fixing or tidying up, thus strengthening the argument for making the markup compliant in the first place.
If you won't be given time later, do it now.
If you are given time later, then you had the time to do it anyway.
If you want your sight to be accessible to people with and without disabilities, as well as external systems, then yes, you should definitely make sure you output valid HTML.
It's easy to test your HTML with automatic validators.
I'll add to what Mike Edwards said about legal ramifications and remind you that you have a moral obligation too :)
Why not write the prototype in valid (X)HTML in the first place? I've never found that to be more of an effort than using invalid HTML. Producing valid XHTML should be a trivial task. (On the other hand, producing semantically meaningful XHTML might be more taxing.)
In short, I see no advantage whatsoever in using invalid HTML for prototypes.
I honestly dont know why it is extra effort to do standards based HTML. It's not as if it's hard and you should be doing it as a matter of professionalism.
If you paid someone to build you a house and he cut corners out of laziness, that you didnt notice at the time, but in 10 years cracks appeared in your walls, would you be happy?
Valid HTML just to be able to have a badge on your site - no.
Having "valid HTML" in the sense of "HTML that works on every major browser or browser engine" - yes.
Absolutely. Invalid code can cause all sorts of weird behaviors, and errors which don't obscure those that do when you get a validation report.
Case in point:
A yellow background was spilling out of a list of messages and over the heading for the next list of messages - but only in Internet Explorer.
Why? The background was applied to a list item, but the person who wrote the page had written it as a single list with a heading in the middle. Headings are not allowed between list items and different browsers attempted to recover from it in different ways. Internet Explorer ended the list item (with the background colour) when it saw the start of the following item (after the heading), while other browsers ended it when they saw the end tag for the first list item.
It was the only validity error on the page, so it took only a couple of minutes to track down the problem and fix it.
Because, if you stick to standards, your work will be compatible in the future. User Agents will strive for standard compliance and their quirks non-compliance mode will always be subject to change. This is the way is supposed to be.
Unless you're into that whole IE8 broken standards perpetuation thing that they want to enable by default. -- that's another argument.
Webkit, Gecko, Presto? (is that opera's engine?), and the others will always become more compliant with every release.
Unless your html work is in a IE embedded browser control, then there's really no reason to output valid html as long as it renders.
In my opinion the key criterion is "fit for purpose" - If your clients want something for a small/internal market (and don't care if that alienates potential customers who have disabilities or use less-common browsers) then that's their choice.
At the same time I think it's our (as developers) responsibility to make sure they know the implications of their decisions - Some organisations will be bound by legislative requirements that websites be useable by screen readers, which typically means standards-compliant HTML.
i believe making valid html outputs wont hurt your development time that much if you've trained yourself to code valid html from the start. for one, its not that hard to know which tags are not allowed within an elementand the required attributes in a tag are sometimes the ones you'd really need anyway - i believe these are the main errors that makes your html invalid, so why not just learn them as early as now if you plan to stay on the web for long?plus outputting valid html can help boost your sites ranking
There are two rules for writing websites:
The site must work for your users.
The site must work for your users.
To meet the first rule, you have to code such that your site renders correctly when using Internet Explorer. Unless you have the freedom to alter your site design to use only those features that IE renders correctly, this means writing invalid HTML.
To meet the second rule, you have to code such that your site renders correctly when using screen-readers and braille screens. Although some newer screen readers can work with IE-targeted sites, in general this means writing valid HTML.
If you're working on a small project, or you're part of a large team, you can code a site that outputs IE-targeted HTML for IE, and valid HTML otherwise. But if you're taking on a medium-to-large project on your own, you have to decide which rule you're going to follow and which one you're going to ignore.
UPDATE:
This is getting voted down by users who think you can always get away with valid HTML in IE. That may be true if you have the flexibility to change your design to get around IE's shortcomings, but if a client has given you a design and you have to get it working, you may have to resort to invalid HTML. It's sad, but it's true, whatever they might think.