I'm trying hard to understand the proccess of W3C's workflow. The main thing that I'm trying to understand at the moment is how do they choose what level is particular CSS module.
For example there is only "CSS Intrinsic & Extrinsic Sizing Level 3" and no information about what was happening to this module before, was it ever level 2, or it started from level 3?
And another, bonus question, why some modules in "Working Draft" status are supported wider by browsers than modules in "Candidate recomendation" status.
How do they choose what level is particular css module?
From the CSS 2017 Snapshot:
Modules with no CSS Level 2 equivalent start at Level 1; modules that update features that existed in CSS Level 2 start at Level 3.
Why some modules in "Working Draft" status are supported wider by browsers than modules in "Candidate recomendation" status?
Writing specifications and implementations of them are iterative processes. Problems with existing specs such as missing capabilities or undefined situations are identified, and initial specifications may be written to address them. Then browser makers may prioritise them according to commercial advantage balanced against ease of implementation, or even if an individual developer or group has a particular interest or skill in that area. This in turn leads to knowledge about what works and what doesn't which then gets fed back into producing a better spec. These iterations can continue indefinitely until all the browser makers are satisfied that they've got the spec right and that sufficient implementations meet that spec. Only then can it proceed to recommendation. Each module proceeds at its own pace, and so there are no rules as to where each one is in the process relative to other CSS specs.
Related
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.
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 would like to know if CSS3 is an official W3C standard or just something like "CR" (Candidate Recommendation)?
CSS3 is described as the next generation of the CSS styling language (just like HTML5 is the next generation of HTML), building upon the foundation set by CSS2.1, the de jure CSS level 2 spec. It is still in active development and has not entirely been finalized yet.
In fact, CSS3 will probably never reach a "final" state in the sense of the word, as new modules are being added all the time. This is because starting from level 3, CSS itself has been modularized, such that each module can be developed independently of the rest (although related modules may be developed in tandem). This allows not just for existing modules to be leveled independently, but new modules to be created at any time, either defining completely new sets of features, or extending from existing CSS2.1 features.
Modules that are based on existing sections of the CSS2.1 spec start off at level 3, while modules that are entirely new to CSS as a whole start from level 1. Now, although "level 4" would seem to imply that there is a CSS4 coming, just as how "level 3" is often used to refer to CSS3, one of the CSSWG members has published a blog post talking about the term "CSS4" saying that is not the case:
THERE IS NO SUCH THING AS CSS4
There has never been a CSS4. There will never be a CSS4. CSS4 is not a thing that exists.
The term "CSS3" refers to everything published after CSS 2.1.
CSS is on its last version as a language as a whole, so it would be appropriate to just drop the number entirely and refer to everything from now on as just "CSS".
While trying to finish CSS 2.1, we (the CSSWG) realized that big monolithic "versions" weren't any good. They were difficult to maintain, and slow to develop.
Instead, we decided to split up the CSS language into a bunch of independent modules. Each module can level up independently, and contains only a smallish set of features, so it's harder for a large set of features to be slowed down by a single stubborn feature.
Some of our modules start out at level 3, if they extend something from CSS2.1. Others start out at level 1, if they're something new (for example, Flexbox). However, the level that a module is at has no correlation with what version of CSS it's in. They're all CSS3 (or just CSS), regardless of what level they're at.
Because each module is developed independently, as of 2012, only certain modules have reached or surpassed the Candidate Recommendation (CR) stage. Notable ones include:
Media Queries
Namespaces
Colors
Selectors
Backgrounds and Borders
Image Values and Replaced Content
Multi-column Layout
Values and Units
Most of the dozens of other modules are still in draft, and it may take a few months or years before they reach CR, PR or REC. And as mentioned, more are being added all the time, and these will be leveled in their own pace as well.
For information on the status of development of CSS, see the following pages:
CSS Current Status - W3C. Specifications listed under Standards have been standardized as W3C Recommendations. This is maintained by W3C; the specifications themselves, however, are maintained by the CSS Working Group, who are directly involved in the development of CSS.
CSS Current Work. There's a table of specifications here so you can see at a glance how mature each module is in development. This page is maintained by the CSS Working Group.
W3C CSS WG Note. This page describes the development process of the CSS standard. It mentions the term "level", which is used to describe each revision of the CSS standard rather than the term "version":
2. CSS Levels
Cascading Style Sheets does not have versions in the traditional sense; instead it has levels. Each level of CSS builds on the previous, refining definitions and adding features. The feature set of each higher level is a superset of any lower level, and the behavior allowed for a given feature in a higher level is a subset of that allowed in the lower levels. A user agent conforming to a higher level of CSS is thus also conformant to all lower levels.
Additionally, given this modularization of CSS, and the completion and standardization of some modules, work has begun on level 4 of these modules, for example Backgrounds and Borders, and Selectors. However, since these modules have just started, don't expect vendors to start supporting these modules for at least another year. As mentioned above, while these modules are progressing to level 4, they aren't officially defined or versioned as "CSS4".
No, CSS3 is a collective name for a W3C activity of developing CSS. W3C isn’t really a standards body at all; it issues recommendations, and only a few of the areas of CSS3 activity have resulted in recommendations so far. Most of the areas have produced working drafts, which carry the following boilerplate text: “This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.”
So we should make accessible web sites, providing alt attribute for img elements and all other stuff. But although this effects comparatively lesser number of users, I could not find any information to the issues that effects each and every user.
Let me explain. If we were to simplify matters by saying that web sites should provide the most revelant information in the least amount of time, would I be wrong? Given this axion if I were to
1 - Want to download the offline version of Acrobat Reader X. There is nothing, and I mean nothing on the site http://www.adobe.com/products/reader.html which provides a hint, link or anything to that. I have to use google to find ftp://ftp.adobe.com/pub/adobe/reader/
2 - Again trying to find the offline version of Google Chrome at http://www.google.com/chrome/ . Nothing there that may lead to http://www.google.com/chrome/eula.html?standalone=1
3 - So Internet Explorer has an addon called Web Developer Tool Bar. It is safe to assume I will find it at http://www.ieaddons.com/in/. No such luck. Have to google it again and find it at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=95e06cbe-4940-4218-b75d-b8856fced535
4 - Trying to get the the Firebug addon from https://addons.mozilla.org/en-US/firefox/extensions/web-development/. Successfully navigated to web development. You can use "view all recetally added" or "view all top downloads" or "view all top rated". What if you want to view all for web development. Offcouse you sue the search!
These are just some of the situations. I guess my question would be that are these not accessibility issues?
If the issues you are are describing apply equally to say sighted users as to blind users using a screenreader, then no, they are not considered to be accessibility issues, but are perhaps broader usability issues.
If, for example, the adobe web site had no link at all to the offline version, and all users, sighted or not, had to do extra work to find it, that's a usability issue.
But if the web site had a graphic image that sighted users could see was a link to the download, but users using a screenreader did not get this information (eg. because the graphic had no ALT text, or the image was not operable via keyboard), then it's an accessibility issue.
There's certainly overlap between these; and it's often the case that usability issues are harder for disabled users to work around; but generally accessibility refers to cases where the design of a site confronts a user with a disability with additional barriers or challenges beyond those that users without a disability have to deal with.
I think it depends on your definition. Some definitions describe accessibility assuming that the correct website is known and is concerned only with the accessibility of that website. Others do describe the ease of users finding the required resource on the Web, which would encapsulate your issues above.
There are two reasons why accessibility is a failure on the web, and for these failures the technology HTML is to blame for both.
1) HTML is not self-validating. SGML does not have a direct self-validating subset and all versions of HTML < 5 are subsets of SGML. HTML5 is based upon a specification document not vested in any computer language, so its perhaps more lost.
XML does have a direct self-validating subset called schema. There are three widely recognized schema languages for XML: Schematron, Relax NG, W3C XML Schema (official).
By self-validating I mean that the language itself can be called to validate its instances without external assistance from the local parser. Without a self-validating component there is no assurance of integrity of a document's structure, and therefore there is no integrity of accessibility. In a world where web browsers will parse anything without regard for the proper well-formedness of a structure then by practice everything is acceptable completely without regard for accessibility.
2) Less obvious and more devastating is that HTML does not understand its own structure. There are two levels of structure as defined in the HTML specifications: block-level elements and inline elements. According to the specifications the difference between these two structure levels is vested primarily in the visual intention of the elements' presentation, which contradicts other language in the specifications in that HTML is a data structure and not a presentational language.
Furthermore, two levels of structure is insufficient and the actual structural definition of HTML elements exceeds a two level structure anyways without inherently stating such. For example in HTML many block-level elements may contain a 'p' element representing a paragraph, but such an element may not contain other block level elements although many other block level elements may certainly contain block level children.
At a minimum a three level structure is required to describe natural language in a manner consumable to a human audience equally without need for further accessibility assistance. In accordance with the structure defined in Mail Markup Language there would be:
Complex blocks
Simple blocks
Inline elements
Complex blocks are purely structural in that they may contain simple blocks, or in some cases other complex block elements, but will never contain inline elements or text nodes. Simple blocks will never contain complex block or simple block elements, but may contain inline elements or text nodes. Inline elements be either singletons containing nothing or will contain text nodes, but inline elements will never contain other elements.
Such a structure is self-sufficient in properly arranging and structuring content so that accessibility requirements are met immediately in a manner where violations of accessibility requirements are more costly and complex than simple conformance to the given structure. Once a sufficient structure is in place all that is missing is the meta data supplied via descriptive and well-known element names, and in some cases additional extraneous content via attributes.
If either of these two items are missing a minimum baseline for accessibility cannot be assured. When they are both missing, as with the web, then accessibility is likely a lost cause and immediate failure.
Web accessibility
Website is made up of different contents like images, texts, videos, button, etc, with combination of different colors.
Web accessibility means that people with disabilities can use the Web.
Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.
Web accessibility also benefits others, including older people with changing abilities due to aging.
The main theme of web accessibility is creating a website which is accessible to every one. After designing a website it is essential to check the website ADA compliance, whether it is accessible and how much it is user friendly for disabled people.
I understand that some countries have laws regarding website accessibility. In general, what are the minimum requirements that a website must meet to be accessible, regardless of country? Or, in lieu of minimum requirements, what are some specific things that websites should have to make the accessible?
W3C publishes Web Content Accessibility Guidelines:
http://www.w3.org/TR/WAI-WEBCONTENT/
If you want a quick summary list, look for the yellow-highlighted lines in that document. Each guideline is also broken down into specific requirements ("checkpoints") in one of three priorities - to claim any kind of accessibility under this scheme you must satisfy all priority 1 checkpoints, but they're "necessary" rather than "sufficient" conditions.
Looking at your pages in lynx is also a good measure - if it won't render in text, chances are good that a screen reader will have a difficult time of it too.
I recommend A-prompt for testing of Accessibility.
It is free and it can really help.
I also recommend Mark Pilgrim's online text - Dive into Accessibility.
It's not a binary question, and there's no silver bullet. Making sure you follow at least the basics of WCAG and testing in a couple of screen readers and without the mouse will probably be the most effective use of your time. If at all possible, test with real people with real disabilities, they have a perspective that is hard for fully-abled people to attain.
Well, obviously the law in different countries varies vastly. In the UK, for example, we don't have any specific web-accessibility laws, but no service is allowed to discriminate against someone with a sight or hearing impediment, insofar as it relates to functionality.
In light of this, a simplistic way to design would be to ensure that your website is readable by screen-readers, can be tabbed through successfully and in a logical order, and allows the scaling of screen elements (including images and font sizes) correctly for those who require web-pages to be magnified.
In addition, your website should have functionality fall-backs in place for any JavaScript and Flash, such that if they were turned off (such as is the case in many screen readers) all functionality is still usable. Don't rely on WAI-ARIA for JavaScript accessibility, as it isn't standardised, and it isn't widely supported.
Of course, this doesn't necessarily cover every possible law, but it's a good starting point. If your website meets the above 'criteria', you're likely to have a good level of accessibility. There is a test for accessibility, of sorts, following WCAG but it's by no means 'conclusive' for what is an acceptable level of accessibility in each individual country.