Chapters 1-8 PDF Rollup
Chapters 1-8 PDF Rollup
http://www.yonaitis.com/A Horror of an Office.pdf
428 kb
Thursday, September 24, 2009
The Northern way of looking at new standards (HTML5)
Last week I was at a very interesting conference in London. During the conference a few questions on HTML five were posed to the attendees as related to accessibility features and whether they should be removed or included. One example was the table summary attribute. The question was should it be deprecated and if it had value- should it not be visible to all. I found this interesting and it lined up with other questions of the day such as redundant usage of Title and Alt attributes for form fields.
So, as an old-timer (yes I can now wear that title), I am against deprecated items, so why deprecate the summary attribute? I think this question itself is simply a group of developers assigning value judgments to something based on how they see the future working. When I hear this, the first thing I feel, a guttural reaction, is STOP.
There were two questions; One should it be removed and two if it was valuable should the summary be visible versus a non-display attribute. I will deal with both questions at the same time; Why not, by default, keep it the way it is and add a new attribute called “summary-visible” if you want as a way of answering! Personally I think leaving it the way it is works.
There are many sayings that I can think of, like; “if it isn’t broke do not fix it.” OK, I digress. In the north we have a way of going out into the wild. We understand the utility of clothes. Let’s say you were going to drop me onto Mt. Washington, New Hampshire, USA. This mountain is known to have some of the worst weather in the world. So, if I was going to be dropped, I would want layers- all that the North Face could offer. So even if you were dropping me on a day where it was 60 degrees and sunny, with no wind I would want to be prepared.
In the north we know that if you are too warm you can always take off a layer, we do not fear this, and we embrace this fact. It is not having too much that is a threat but rather it is having too little. If you drop me on the mountain in a t-shirt and shorts because it is all I need today or at the moment then I do not have layers at my disposal. I will not be prepared if the weather declines. You have taken away my choices.
Back to the conference-in addition to the table summary attribute new form fields were also discussed and the question was what levels of styles should be allowed. I go back to the layers, give us a slider or a submit button and let us style it how we want and leave options open for people to override the designer via the browser.
By doing this you make it easy to train young engineers that they should follow standards. To not do this and to say that an attribute was deprecated because some people in an ivory tower decided it’s time had come is at best a poor and makes it difficult on those who train on the importance of not using deprecated elements.
I would suggest that the people working on HTML 5, making decisions on what to throw out, think of the northern way. Once you throw out the summary attribute and others that have utility-you may not get them back. By leaving the attribute as valid you do no harm, in fact you just give another layer that can be peeled back if not needed. It is always easy to take off a layer if you are too hot on the mountain but if you are too cold and have no layer to put back on you are out of luck. One can never go wrong by providing choice, if it is there you can use it if you want to if it is not, well you will be cold on the mountain. The frame of mind on the new standard as items are removed must be does it hurt to leave it alone or does it hurt to add it, if not add it. Looking back, I remember I was told XHTML or nothing, now it is HTML5. We know that what is to be the standard has a short life and innovation will replace it soon enough it should be made easy to adopt.
So, as an old-timer (yes I can now wear that title), I am against deprecated items, so why deprecate the summary attribute? I think this question itself is simply a group of developers assigning value judgments to something based on how they see the future working. When I hear this, the first thing I feel, a guttural reaction, is STOP.
There were two questions; One should it be removed and two if it was valuable should the summary be visible versus a non-display attribute. I will deal with both questions at the same time; Why not, by default, keep it the way it is and add a new attribute called “summary-visible” if you want as a way of answering! Personally I think leaving it the way it is works.
There are many sayings that I can think of, like; “if it isn’t broke do not fix it.” OK, I digress. In the north we have a way of going out into the wild. We understand the utility of clothes. Let’s say you were going to drop me onto Mt. Washington, New Hampshire, USA. This mountain is known to have some of the worst weather in the world. So, if I was going to be dropped, I would want layers- all that the North Face could offer. So even if you were dropping me on a day where it was 60 degrees and sunny, with no wind I would want to be prepared.
In the north we know that if you are too warm you can always take off a layer, we do not fear this, and we embrace this fact. It is not having too much that is a threat but rather it is having too little. If you drop me on the mountain in a t-shirt and shorts because it is all I need today or at the moment then I do not have layers at my disposal. I will not be prepared if the weather declines. You have taken away my choices.
Back to the conference-in addition to the table summary attribute new form fields were also discussed and the question was what levels of styles should be allowed. I go back to the layers, give us a slider or a submit button and let us style it how we want and leave options open for people to override the designer via the browser.
By doing this you make it easy to train young engineers that they should follow standards. To not do this and to say that an attribute was deprecated because some people in an ivory tower decided it’s time had come is at best a poor and makes it difficult on those who train on the importance of not using deprecated elements.
I would suggest that the people working on HTML 5, making decisions on what to throw out, think of the northern way. Once you throw out the summary attribute and others that have utility-you may not get them back. By leaving the attribute as valid you do no harm, in fact you just give another layer that can be peeled back if not needed. It is always easy to take off a layer if you are too hot on the mountain but if you are too cold and have no layer to put back on you are out of luck. One can never go wrong by providing choice, if it is there you can use it if you want to if it is not, well you will be cold on the mountain. The frame of mind on the new standard as items are removed must be does it hurt to leave it alone or does it hurt to add it, if not add it. Looking back, I remember I was told XHTML or nothing, now it is HTML5. We know that what is to be the standard has a short life and innovation will replace it soon enough it should be made easy to adopt.
Thursday, September 3, 2009
CynthiaSays why it was created and why the W3C needs to create a WCAG Tester by Ryonaitis HiSoftware Founder
What is Cynthia Says
Cynthia Says (Cynthia) is a publicly available WCAG and Section 508 Validation tool. As stated on the web site, the validation and reports that the site generates via the Cynthia Agent are an Extension of the AccMonitor Enterprise Server Application Programmers interface (API). Cynthia Says as envisioned by its creator, Robert B. Yonaitis (Yonaitis), was to be an educational tool that when used carried a badge of commitment from the user. This commitment was to strive towards achieving and maintaining Web Accessibility It was not the first testing tool of its kind but it had a distinct and different purpose. Its purpose was to educate while providing actionable reports back to the users of the web service. The reports themselves were designed to be readable by Web site developers and Web application developers.
Why Cynthia
Web sites being created at the time of Cynthia’s creation frequently carried badges. These badges had statements like “Bobby Approved” or other “approved by” logos from other testing tools. The problem with the “badge mentality” was that once a developer tested the page, and put the badge on the tested page, the developer would make the assumption the task was complete. This is not to say the Bobby badge was incorrect, in fact the Bobby Web site was developed and maintained by industry pioneers and the badge itself promoted accessibility. However the static “approved” logo, falsely led user and site visitors to the assumption that a site might be accessible. Because the test was done at a static point and time, ongoing accessibility efforts sometimes went astray, or were not done at all. When Yonaitis first developed the idea of Cynthia it was not to replace Bobby but to instead approach the same problem from a different viewpoint. The goals that Yonaitis put forward were:
· A commitment button and creed versus approved
· Enterprise Ready with Easy Access
· Support Education and Outreach
· Support for 508, WCAG, and Alternative Text Quality Reporting
· A report that could be printed and distributed freely by site users
Commitment versus complete
Developers can look back to the days when Web sites were static pages, never changing from the first day they were published, that is unless the site owner moved their brick and mortar store and needed to update their address. Cynthia was brought into play in a world where static sites were no longer the norm. The Cynthia tested button and commitment were seen as a way of addressing several changes in development from dynamic content and m ore Web based applications coupled with the desire to deal with reality versus marketing hype. Yonaitis wanted to promote the reality that accessible design and testing was incomplete, if there were not components of both programmatic and manual tests included as part of the process. The manual tests for each guideline were also posted in the printable Cynthia report. While many tools were telling the developer that the site tested was fine or “Healthy” the commitment button told the developer that the process had started but was not complete. Not only were there more human validation requirements but also these requirements required the developer to continue becoming educated in accessible design.
Enterprise Ready
Yonaitis had a background in Enterprise System Design and Architecture and when developing Cynthia it was a fore stated goal that this web service needed to be stable enough to handle thousands of users a day, countless concurrent users, and for speed purposes messaging versus database would be applied. Uptime was important and that would be monitored for responsiveness. In addition to the speed concerns there were access concerns. There were multiple sites that allowed you to register for a “free” accessibility test, including the old AccessibilityWatch web site and Ask Alice. These sites were for lead generation and arguably did not do much to promote or educate developers with regards to accessibility. This is not because the technology was not good, but rather because people were averse to giving their email addresses to gain access as spam was a concern. So Cynthia would be public and freely available without registration and there would be no tracking of users or marketing to the same.
Support Education and Outreach
Yonaitis had learned early on that not only was accessibility testing a market that could be served but also it represented an important responsibility. In the early days at Hiawatha Island Software (HiSoftware,) a federal customer approached the company. The customer had made a purchase of a competitor’s server (the company no longer exists) and it did not work as advertised, nor did it really validate content against the Web Content Accessibility Guidelines. Yonaitis learned from this that it was important to educate the user base in two ways; First, get Cynthia out there, promote it, and suggest people compare any tool they were planning to purchase to Cynthia results for simple reference, and second, use a complete checklist of what to expect in a solution and make it available through the company Web site. This could be completed by the user as a start in making a solution acquisition decision. Finally there was the compilation.
Yonaitis knew that while people cared about Accessibility, indicated by using the Cynthia solution, that they would make mistakes. Many Accessibility mistakes are made for two reasons; first, the developer is unaware and second, the developer is using a bad method. So as Cynthia started to gain wide spread usage, Yonaitis was able to review the material and come up wit h teaching and educational objectives. This empowered the trainers and evangelists to go to their constituents and discuss best practices and most common mistakes. The last and perhaps the most important gain was the ability to provide a method that allowed users to enable the Cynthia tester to run from their site or from popular browsers.
Support Standards
A simple but important task was to implement the tester to support current well known accessibility and accessibility quality standards, while at the same time ensuring that the Cynthia site and output fully complied with W3C standards. The site was implemented (the current state of the site is out of the authors control) to comply with standards as was the output. The testing rules were also validated with the Access board and in some cases tweaks to the testing settings were made.
The Report
An interesting argument today and back in the day was the need for or use of reports. Cynthia as an individual page tester could and should give a report. The report is essential to the web developer and it applied some basic rules to the checkpoints. The rules were as follow:
· If the page that was tested passed a checkpoint the word “Yes” would appear
· If the page that was tested failed a checkpoint the word “No” would appear
· If the page that was tested had a checkpoint that the system did not validate then an “N/V” would appear
· If the page that was tested had a checkpoint that the system did validate and no applicable elements were found then a “N/A” would appear
· If the page that was tested had a checkpoint that the system did validate and found applicable elements but could not make a determination then there would be no result as a human needed to validate the page
Because all accessibility validation required a human component , the individual report was needed to complete the checklist of work that was being done. The report itself could be electronic or printed but was an overarching requirement for a report that could go to the most granular page and checkpoint level. The report was also designed so that it could be used as a teaching tool. With this in mind every report checkpoint would link back to the techniques that were used to comply with the specific standard. These in turn linked back to the standards official web site without interpretation.
The Future
Cynthia as a Web service is no longer up to date with the current technologies but still keeps a valid and wide internet audience. Cynthia is embedded in browsers and developer toolbars such as IE 7 and IE 8, at last check. The developers including but not limited to Yonaitis, have all moved on and there are many new standards that are not being addressed. There are also many new tools that are available in multiple languages and all are open source. Some of the tools are:
· Achecker: http://www.atutor.ca/achecker/index.php, a Checker supports WCAG 1, WCAG 2, BITV 1, Sec 508, and the Stanca Act ad has a web services API
· Hera: http://www.sidar.org/hera/ which supports WCAG 1 and a WCAG 2 version is soon to be released.
These tools are both open source and have unique characteristics that give them advantages over Cynthia. They are also open source and can be included on your own servers. These tools are not part of a commercial entity so they are the main business and are not competing with any commercial offerings. Regardless of these two competent tools this author thinks it is time for the W3C to make available a WCAG 2.0 tester much like their HTML or CSS Validation utilities on the W3C’s web site. By doing this the W3C will have several benefits; first the W3C will have control over what is the baseline testing that will be considered passing, failing, N/A, needing further review and secondly the education and outreach working group can tabulate most common errors allowing for more efficient education and outreach. The US government should also look into doing the same for Section 508.
Cynthia Says (Cynthia) is a publicly available WCAG and Section 508 Validation tool. As stated on the web site, the validation and reports that the site generates via the Cynthia Agent are an Extension of the AccMonitor Enterprise Server Application Programmers interface (API). Cynthia Says as envisioned by its creator, Robert B. Yonaitis (Yonaitis), was to be an educational tool that when used carried a badge of commitment from the user. This commitment was to strive towards achieving and maintaining Web Accessibility It was not the first testing tool of its kind but it had a distinct and different purpose. Its purpose was to educate while providing actionable reports back to the users of the web service. The reports themselves were designed to be readable by Web site developers and Web application developers.
Why Cynthia
Web sites being created at the time of Cynthia’s creation frequently carried badges. These badges had statements like “Bobby Approved” or other “approved by” logos from other testing tools. The problem with the “badge mentality” was that once a developer tested the page, and put the badge on the tested page, the developer would make the assumption the task was complete. This is not to say the Bobby badge was incorrect, in fact the Bobby Web site was developed and maintained by industry pioneers and the badge itself promoted accessibility. However the static “approved” logo, falsely led user and site visitors to the assumption that a site might be accessible. Because the test was done at a static point and time, ongoing accessibility efforts sometimes went astray, or were not done at all. When Yonaitis first developed the idea of Cynthia it was not to replace Bobby but to instead approach the same problem from a different viewpoint. The goals that Yonaitis put forward were:
· A commitment button and creed versus approved
· Enterprise Ready with Easy Access
· Support Education and Outreach
· Support for 508, WCAG, and Alternative Text Quality Reporting
· A report that could be printed and distributed freely by site users
Commitment versus complete
Developers can look back to the days when Web sites were static pages, never changing from the first day they were published, that is unless the site owner moved their brick and mortar store and needed to update their address. Cynthia was brought into play in a world where static sites were no longer the norm. The Cynthia tested button and commitment were seen as a way of addressing several changes in development from dynamic content and m ore Web based applications coupled with the desire to deal with reality versus marketing hype. Yonaitis wanted to promote the reality that accessible design and testing was incomplete, if there were not components of both programmatic and manual tests included as part of the process. The manual tests for each guideline were also posted in the printable Cynthia report. While many tools were telling the developer that the site tested was fine or “Healthy” the commitment button told the developer that the process had started but was not complete. Not only were there more human validation requirements but also these requirements required the developer to continue becoming educated in accessible design.
Enterprise Ready
Yonaitis had a background in Enterprise System Design and Architecture and when developing Cynthia it was a fore stated goal that this web service needed to be stable enough to handle thousands of users a day, countless concurrent users, and for speed purposes messaging versus database would be applied. Uptime was important and that would be monitored for responsiveness. In addition to the speed concerns there were access concerns. There were multiple sites that allowed you to register for a “free” accessibility test, including the old AccessibilityWatch web site and Ask Alice. These sites were for lead generation and arguably did not do much to promote or educate developers with regards to accessibility. This is not because the technology was not good, but rather because people were averse to giving their email addresses to gain access as spam was a concern. So Cynthia would be public and freely available without registration and there would be no tracking of users or marketing to the same.
Support Education and Outreach
Yonaitis had learned early on that not only was accessibility testing a market that could be served but also it represented an important responsibility. In the early days at Hiawatha Island Software (HiSoftware,) a federal customer approached the company. The customer had made a purchase of a competitor’s server (the company no longer exists) and it did not work as advertised, nor did it really validate content against the Web Content Accessibility Guidelines. Yonaitis learned from this that it was important to educate the user base in two ways; First, get Cynthia out there, promote it, and suggest people compare any tool they were planning to purchase to Cynthia results for simple reference, and second, use a complete checklist of what to expect in a solution and make it available through the company Web site. This could be completed by the user as a start in making a solution acquisition decision. Finally there was the compilation.
Yonaitis knew that while people cared about Accessibility, indicated by using the Cynthia solution, that they would make mistakes. Many Accessibility mistakes are made for two reasons; first, the developer is unaware and second, the developer is using a bad method. So as Cynthia started to gain wide spread usage, Yonaitis was able to review the material and come up wit h teaching and educational objectives. This empowered the trainers and evangelists to go to their constituents and discuss best practices and most common mistakes. The last and perhaps the most important gain was the ability to provide a method that allowed users to enable the Cynthia tester to run from their site or from popular browsers.
Support Standards
A simple but important task was to implement the tester to support current well known accessibility and accessibility quality standards, while at the same time ensuring that the Cynthia site and output fully complied with W3C standards. The site was implemented (the current state of the site is out of the authors control) to comply with standards as was the output. The testing rules were also validated with the Access board and in some cases tweaks to the testing settings were made.
The Report
An interesting argument today and back in the day was the need for or use of reports. Cynthia as an individual page tester could and should give a report. The report is essential to the web developer and it applied some basic rules to the checkpoints. The rules were as follow:
· If the page that was tested passed a checkpoint the word “Yes” would appear
· If the page that was tested failed a checkpoint the word “No” would appear
· If the page that was tested had a checkpoint that the system did not validate then an “N/V” would appear
· If the page that was tested had a checkpoint that the system did validate and no applicable elements were found then a “N/A” would appear
· If the page that was tested had a checkpoint that the system did validate and found applicable elements but could not make a determination then there would be no result as a human needed to validate the page
Because all accessibility validation required a human component , the individual report was needed to complete the checklist of work that was being done. The report itself could be electronic or printed but was an overarching requirement for a report that could go to the most granular page and checkpoint level. The report was also designed so that it could be used as a teaching tool. With this in mind every report checkpoint would link back to the techniques that were used to comply with the specific standard. These in turn linked back to the standards official web site without interpretation.
The Future
Cynthia as a Web service is no longer up to date with the current technologies but still keeps a valid and wide internet audience. Cynthia is embedded in browsers and developer toolbars such as IE 7 and IE 8, at last check. The developers including but not limited to Yonaitis, have all moved on and there are many new standards that are not being addressed. There are also many new tools that are available in multiple languages and all are open source. Some of the tools are:
· Achecker: http://www.atutor.ca/achecker/index.php, a Checker supports WCAG 1, WCAG 2, BITV 1, Sec 508, and the Stanca Act ad has a web services API
· Hera: http://www.sidar.org/hera/ which supports WCAG 1 and a WCAG 2 version is soon to be released.
These tools are both open source and have unique characteristics that give them advantages over Cynthia. They are also open source and can be included on your own servers. These tools are not part of a commercial entity so they are the main business and are not competing with any commercial offerings. Regardless of these two competent tools this author thinks it is time for the W3C to make available a WCAG 2.0 tester much like their HTML or CSS Validation utilities on the W3C’s web site. By doing this the W3C will have several benefits; first the W3C will have control over what is the baseline testing that will be considered passing, failing, N/A, needing further review and secondly the education and outreach working group can tabulate most common errors allowing for more efficient education and outreach. The US government should also look into doing the same for Section 508.
Tuesday, September 1, 2009
Retweet :)
Averaging around 100 visitors a day on my new Novella, A Horror of an Office -- Yeah! 6 Chapters; http://tinyurl.com/nls5ak
Subscribe to:
Posts (Atom)
