508 Compliance - ASP.NET webforms Update Panels - updatepanel

Has anyone faced any issues with using AJAX with update panels and keeping their sites 508/ Accessibility compliant? Is there a way to detect that javascript is turned off and force update panels to work as synchronous?

Section 508 guidelines are moving toward WCAG 2.0.
http://www.access-board.gov/sec508/refresh/draft-rule.htm#e107
E107 WCAG 2.0 Harmonization
Web pages as defined by WCAG 2.0, that are Level AA conformant to WCAG 2.0, as defined in >that standard, (that is, all Level A and Level AA Success Criteria and Conformance >Requirements 1 - 4) shall be deemed to be in conformance with the following chapters of >this part, so long as they also meet the enumerated sections of this part:
Chapter 4, all corresponding WCAG 2.0 Success Criteria and Conformance Requirements plus sections 409 and 413 of this part;
Chapter 5, all corresponding WCAG 2.0 Success Criteria and Conformance Requirements;
Chapter 6, all corresponding WCAG 2.0 Success Criteria and Conformance Requirements plus sections 604.4, 604.5, 607, and 608 of this part.
Advisory E107 WCAG 2.0 Harmonization. The WCAG 2.0 definition for web page is available >via the Internet at http://www.w3.org/TR/WCAG20/#webpagedef.
The WCAG 2.0 definition for conformance is available via the Internet at
http://www.w3.org/TR/WCAG20/#conformance.
WAI-ARIA is a critical technology for making dynamic web sites accessible. This relates directly to using UpdatePanels. Using WAI-ARIA tags, assistive technology can receive notifications from the browser, via the accessibility API, that a panel has been updated. Using WAI-ARIA, you don't have to be as concerned about making a synchronous request for new content. However, if you are still concerned, look into using a technique called 'progressive enhancement.'
Using the WAI-ARIA approach will move your application toward the future of accessibility and have it in good shape for the 508 harmonization with WCAG 2.0.
This is a big topic, so you'll likely have more questions.

As long as you don't trigger post back using JavaScript exclusively, then ASP.NET will fall back to regular post backs, which are basically HTML form submissions. Server side page life cycle is more or less the same using <asp:UpdatePanel> so given that, your page should degrade gracefully.
Where you may get into problems is when you must use a control like the <asp:LinkButton> as this control relies on JavaScript to perform a post back. You can work around this using the following (example) code:
<noscript>
<asp:Button runat="server" OnClick="Click_Handler" Text="Update" />
</noscript>
<asp:LinkButton runat="server" OnClick="Click_Handler" Text="Update" />
Clients that do not support JavaScript should render the regular button first, other browsers should ignore it. To increase usability you should consider showing the link element using JavaScript:
<span class="hidden">
<asp:LinkButton runat="server" OnClick="Click_Handler" Text="Update" />
</span>
<script type="text/javascript">
// PSEUDO CODE:
document.ready ? for each span.hidden : show
</script>
JavaScript-based post back can occur for several controls and events, not just the LinkButton (e.g. DropDown control with AutoPostBack="True" or TextBox with OnTextChanged event).

Related

Accessibility and links that are buttons and vice versa

Can someone advise me if there is a specific WCAG 2.1 failure when buttons are used as links. Same question vice versa. Links as buttons.
I have a site i am working on where by design there are links that appear the same as the buttons do.
So you may have buttons <button> like:
Edit details - which takes you to a new page where you can edit items in the page where the "edit details resides".
Continue - a button that takes you to the next page in a series of pages.
But then have links <a> which appear as buttons, so the same style, but they are labelled select, select and selected and these are a product type, so do not link anywhere.
Another example is the back link is a button<button> but looks like a link (text with underlined style)!
I know that this behavior confuses voice recognition as the user says click link or click buttonand not all objects get flagged that appear the same.
My question is does this fail WCAG2.1 specifically? Would this fall under 4.1.2 Name, Role, Value?
The 4.1.2: Name, Role, Value undestanding addresses the case of elements having different role than usual.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
As Adam already cited, "additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies". So yes, this fails WCAG 2.1, unless you take measures to ensure that your button-links and link-buttons really work as they are supposed to for example that a <a role="button" […] can be triggered using the Space key.
If you really have accessibility in mind, don't mix <button> and <a> elements up. Not even if you think you are smart and add role="button" to a link or role="link to a button. You would have to do more than that to make them behave like each other (see MDN about the button role).
And even then you should consider this: links are for navigation, buttons for performing actions. If you have a navigational element that looks like a button, its behavior might be confusing (even if it has no role="button" attribute). Also note that the default value for a button's type attribute is submit ("The missing value default and invalid value default are the Submit Button state.").
Web accessibility should encompass all disabilities that affect access to the Web and there are a lot of possible disabilities – and having one disability does not necessarily mean a person has no other disabilities.
The easiest step of making your website more accessible is to stick to the standards. Don't change an element's behavior unless you really have to (and even then: do you really have to?).
Update: General comment about WCAG and accessibility:
Web accessibility is also not just about simply conforming to guidelines like the WCAG. Even the WCAG itself does not claim that a website will be 100% accessible when conforming to it:
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.
Update: Examples of possible violations of WCAG 2.1 (with room for interpretation though)
Just letting links look like buttons and nothing could be failing:
Guideline 3.2 Predictable in general ("Make Web pages appear and operate in predictable ways.")
Success Criterion 3.2.4 Consistent Identification (unless all links look like buttons; the only actual success criterion in these examples)
4. Robust in general ("Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies." & Guideline 4.1 Compatible "Maximize compatibility with current and future user agents, including assistive technologies." --> you already mentioned voice recognition and the possibility of not being able to target a link because it looks like a button)
Jonathan Pool wrote a blog article about this issue in which he points out another possible violation:
Worst case: A button that takes an irreversible action ("Yes, I confirm that I am waiving my rights.") pretends to be a link, so the user tries to use SPACE or SHIFT-SPACE to scroll the page but unexpectedly presses the button. This, arguably, would violate Web Content Accessibility Guidelines 2.1 Success Criterion 3.3.4.

Do HTML errors count as WCAG errors?

I am trying to make a website WCAG compliant and read quite a lot about it but still one question remains:
If the document has HTML errors, would it be considered WCAG 2.0 AA compliant?
Following is the report generated by Total Validator. It has 2 diff sections. 1 for HTML errors and other for WCAG errors. Does it mean that if there are HTML errors and WCAG errors, the document would be WCAG compliant?
It is HTML 4, by the way.
HTML errors as such do not count as a violation of WCAG 2.0, though for various constructs, WCAG 2.0 may impose requirements that coincide with requirements in HTML specifications.
If WCAG 2.0 required conformance to HTML specifications, it would have to cite normatively some specific version(s) of some specific HTML specification(s) (thereby causing harmful rigidity) or use loose language, making WCAG 2.0 itself a very moving target (its content would vary, as HTML specifications are changed).
However, Guideline 4.1 (Compatible: Maximize compatibility with current and future user agents, including assistive technologies) requires that “elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features”.
In this sense, some syntactic rules need to be obeyed in order to conform to WCAG 2.0. The scope of this requirement is rather vague, since HTML rules vary by language version, and the wording is somewhat strange an arbitrary-looking. For example, it does not forbid undefined elements, undefined attributes, attribute values that violate (some) HTML specifications, or anything that might be classified as “semantically wrong”. It is far from evident whether e.g. <a href=...><h2>...</h2></a> would violate WCAG 2.0: it is invalid nesting according to HTML 4 but allowed in HTML5 CR.
This differs from WCAG 1.0, which had a a general requirement about using W3C technologies and specifically avoiding deprecated HTML features. It is fair to assume that the change is intentional: WCAG 2.0 conformance criteria intentionally do not include conformance to some HTML specification(s)

What is DOM? (summary and importance)

What is the Document Object Model (DOM)?
I am asking this question because I primarily worked in .NET and I only have limited experience, but I often hear more experienced developers talk about/mention it. I read tutorials online but I am unable to make sense of the whole picture. I know that it is an API!
More specific questions are:
Where is it currently used?
What field(s) of developers use it (ex-.NET developers)?
How relevant is it for all developers in general to understand?
In general terms a DOM is a model for a structured document.
It is a central concept in today's IT and no developer can opt out of DOM. Be it in .net, in HTML, in XML or other domains where it is used.
It applies to all documents (word documents, HTML pages, XML files, etc). In the developer sphere it applies mainly in the HTML and the XML domains with slightly different meanings.
HTML
In the HTML arena, the DOM was introduced to support the revolution called in the late 90ies "dynamic HTML". Before IE4 and Netscape 4.0, HTML documents where not changeable inside the browser (all you had in these remote times to sprite up a web page was "animated GIF" !!!! and HTML was version 3.2).
Therefore dynamically manipulating inside the browser the document sent by the server was a huge revolution and initiated the march towards the attractive web sites we see today.
Javascript had been introduced by Netscape (baptised javascript to surf on the new Java trend, but unrelated) and was supported by both Netscape HTTP servers and Netscape browsers, with Internet Explorer eagerly following the move inside the browser. However When javascript is used to manipulate the content of a document, you need an easy way to designate the part of the document you want to interact with. That's where the DOM comes in. Although HTML 4 is not "well formed", browsers build an internal representation of the page with the "body" element at its top and plenty of html tags below, in a hierarchical organisation (child nodes, parent nodes attributes etc). The DOM is the model underpinning the API that allows to navigate this hierarchy.
Since both Netscape and IE browsers were competing solutions, there was little chance the NS and the IE DOM would converge. The W3C stepped in to allow smaller browser vendors to enter the competition and endeavoured to standardised the DOM. Hence the W3C DOM. All it did was just to introduce another dialect and as everybody knows it took years and two serious competitors to force MS to comply with the standards.
Even though more moderns navigating techniques like JQuery have shorthand notations for the DOM, they internally rely on the DOM.
XML
HTML made obvious the disadvantages of showing leniency towards the "well-formedness" of documents and this ushered a new craze : XML. In the web arena, XML and XSLT were first supported by IE5 and adopted in many more domains than just displaying pages.
To parse XML, in the Java Word mainly, you would develop a SAX parser which is basically a plugin to a SAX engine in which you describe what the engine should do of all the XML events (tags...) it will encounter in the parsed document. Developing a SAX parser is not straightforward but is a low footprint solution.
However you have to develop a specific one for each new document type...
So it was not long before libraries started to appear to parse any document and build an in-memory map of its hierarchy. Because it also had the same concepts of root, parents and children (inherited from SGML through HTML), it was also termed a DOM and the name applies regardless of the library.
Other domains
The concept of DOM is not restricted to or even invented for HTML or XML. A DOM is a general concept applicable to any document, especially those (the vast majority of them do) showing a hierarchical structure in which you need to navigate. You can speak about the DOM of a MS-Word document and there are APIs to navigate these as well.
The DOM is the application programming interface for well-defined HTML and XML structures (per W3C's document). It is used in any place where you interact with the elements of a web page (any element - style, text, attributes, etc). You will hear a lot about the DOM with JavaScript and/or JavaScript libraries, such as jQuery (which, of course, is JavaScript). It is also referenced with Java, ECMAScript, JScript, and VBScript.
If you are programming .NET it is important if you are doing web-based work. If you are doing application programming, it's not as important. The DOM is definitely not a thing of the past - it is used and worked within every day by many developers. With that said, there has been work towards standardization of the DOM across web browsers. (Again, libraries can help hide these differences. This is one reason jQuery is so popular. You don't have to worry about the browser specifics - you just do what you need to do.)
The document I linked to above does a great job of answering all your questions and more. I would highly recommend reading it. If you have more questions, you can also check out the links below:
What is the Document Object Model? (W3C)
Document Object Model (Wikipedia)
I'm really not going to be able to explain it any better than the Wikipedia Article on DOM
But to answer a few of your questions:
Where do we still use it?
Every web browser since the mid-nineties.
Who uses it,
Every web developer since the mid-nineties.
in what technology?
Mostly the web via JavaScript, but pretty much anytime you access XML/HTML programatically you are using some kind of DOM implementation.
How important is it for anyone in .net
carrier? [sic]
Extremely, although you probably use it without even knowing it.
Is this just a thing of the past which
was heavily used but had problems?
If it is then somebody needs to tell John Resig that he has wasted the past 3 years of his life.
When a browser loads an HTML page, its convert it to the Document Object Model (DOM).
The browser's produced HTML DOM, constructs as a tree that consists of all your HTML page element as objects. For example, assuming that you load below HTML page on a browser:
<!DOCTYPE html>
<html>
<head>
<title>website title</title>
</head>
<body>
<p id="js_paragraphId">I'm a paragraph</p>
some website
</body>
</html>
After loading, the browser converts it to:
Some of the ability of scripting languages on HTML DOM consists of:
1- Change all the HTML elements in the page.
2- change all the HTML attributes in the page.
3- Change all the CSS styles on the page.
4- Remove existing HTML elements and attributes.
5- Add new HTML elements and attributes.
6- React to all existing HTML events in the page.
7- create new HTML events on the page.
Let's back to your questions:
1- It currently used in all modern browsers.
2- Front-end developers.
3- All Front-end developers that using scripting languages especially JavaScript.
What is DOM?
The Document Object Model (DOM) is a programming API for HTML and XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. A standard defined by w3 consortium.
Source: http://www.w3.org/TR/WD-DOM/introduction.html

What is HTML5 ARIA?

What is HTML5 ARIA? I do not understand how to implement it.
WAI-ARIA is a spec defining support for accessible web apps. It defines bunch of markup extensions (mostly as attributes on HTML5 elements), which can be used by the web app developer to provide additional information about the semantics of the various elements to assistive technologies like screen readers. Of course, for ARIA to work, the HTTP user agent that interprets the markup needs to support ARIA, but the spec is created in such a way, as to allow down-level user agents to ignore the ARIA-specific markup safely without affecting the web app's functionality.
Here's an example from the ARIA spec:
<ul role="menubar">
<!-- Rule 2A: "File" label via aria-labelledby -->
<li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span>
<ul role="menu">
<!-- Rule 2C: "New" label via Namefrom:contents -->
<li role="menuitem" aria-haspopup="false">New</li>
<li role="menuitem" aria-haspopup="false">Open…</li>
...
</ul>
</li>
...
</ul>
Note the role attribute on the outer <ul> element. This attribute does not affect in any way how the markup is rendered on the screen by the browser; however, browsers that support ARIA will add OS-specific accessibility information to the rendered UI element, so that the screen reader can interpret it as a menu and read it aloud with enough context for the end-user to understand (for example, an explicit "menu" audio hint) and is able to interact with it (for example, voice navigation).
ARIA stands for Accessible Rich Internet Applications.
WAI-ARIA is an incredibly powerful technology that allows developers to easily describe the purpose, state and other functionality of visually rich user interfaces - in a way that can be understood by Assistive Technology. WAI-ARIA has finally been integrated into the current working draft of the HTML 5 specification.
And if you are wondering what WAI-ARIA is, its the same thing.
Please note the terms WAI-ARIA and ARIA refer to the same thing. However, it is more correct to use WAI-ARIA to acknowledge its origins in WAI.
WAI = Web Accessibility Initiative
From the looks of it, ARIA is used for assistive technologies and mostly screen reading.
Most of your doubts will be cleared if you read this article
http://www.w3.org/TR/aria-in-html/
What is it?
WAI-ARIA stands for “Web Accessibility Initiative – Accessible Rich Internet Applications”. It is a set of attributes to help enhance the semantics of a web site or web application to help assistive technologies, such as screen readers for the blind, make sense of certain things that are not native to HTML. The information exposed can range from something as simple as telling a screen reader that activating a link or button just showed or hid more items, to widgets as complex as whole menu systems or hierarchical tree views.
This is achieved by applying roles and state attributes to HTML 4.01 or later markup that has no bearing on layout or browser functionality, but provides additional information for assistive technologies.
One corner stone of WAI-ARIA is the role attribute. It tells the browser to tell the assistive technology that the HTML element used is not actually what the element name suggests, but something else. While it originally is only a div element, this div element may be the container to a list of auto-complete items, in which case a role of “listbox” would be appropriate to use. Likewise, another div that is a child of that container div, and which contains a single option item, should then get a role of “option”. Two divs, but through the roles, totally different meaning. The roles are modeled after commonly used desktop application counterparts.
An exception to this are document landmark roles, which don’t change the actual meaning of the element in question, but provide information about this particular place in a document.
The second corner stone are WAI-ARIA states and properties. They define the state of certain native or WAI-ARIA elements such as if something is collapsed or expanded, a form element is required, something has a popup menu attached to it or the like. These are often dynamic and change their values throughout the lifecycle of a web application, and are usually manipulated via JavaScript.
What is it not?
WAI-ARIA is not intended to influence browser behavior. Unlike a real button element, for example, a div which you pour the role of “button” onto does not give you keyboard focusability, an automatic click handler when Space or Enter are being pressed on it, and other properties that are indiginous to a button. The browser itself does not know that a div with role of “button” is a button, only its accessibility API portion does.
As a consequence, this means that you absolutely have to implement keyboard navigation, focusability and other behavioural patterns known from desktop applications yourself. You can find some Advanced ARIA techniques Here.
When should I not use it?
Yes, that’s correct, this section comes first! Because the first rule of using WAI-ARIA is: Don’t use it unless you absolutely have to! The less WAI-ARIA you have, and the more you can count on using native HTML widgets, the better! There are some more rules to follow, you can check them out here.
What is ARIA?
ARIA emerged as a way to address the accessibility problem of using a markup language intended for documents, HTML, to build user interfaces (UI). HTML includes a great many features to deal with documents (P, h3,UL,TABLE) but only basic UI elements such as A, INPUT and BUTTON. Windows and other operating systems support APIs that allow (Assistive Technology) AT to access the functionality of UI controls. Internet Explorer and other browsers map the native HTML elements to the accessibility API, but the html controls are not as rich as the controls common on desktop operating systems, and are not enough for modern web applications Custom controls can extend html elements to provide the rich UI needed for modern web applications. Before ARIA, the browser had no way to expose this extra richness to the accessibility API or AT. The classic example of this issue is adding a click handler to an image. It creates what appears to be a clickable button to a mouse user, but is still just an image to a keyboard or AT user.
The solution was to create a set of attributes that allow developers to extend HTML with UI semantics. The ARIA term for a group of HTML elements that have custom functionality and use ARIA attributes to map these functions to accessibility APIs is a “Widget. ARIA also provides a means for authors to document the role of content itself, which in turn, allows AT to construct alternate navigation mechanisms for the content that are much easier to use than reading the full text or only iterating over a list of the links.
It is important to remember that in simple cases, it is much preferred to use native HTML controls and style them rather than using ARIA. That is don’t reinvent wheels, or checkboxes, if you don’t have to.
Fortunately, ARIA markup can be added to existing sites without changing the behavior for mainstream users. This greatly reduces the cost of modifying and testing the website or application.
I ran some other question regarding ARIA. But it's content looks more promising for this question. would like to share them
What is ARIA?
If you put effort into making your website accessible to users with a variety of different browsing habits and physical disabilities, you'll likely recognize the role and aria-* attributes. WAI-ARIA (Accessible Rich Internet Applications) is a method of providing ways to define your dynamic web content and applications so that people with disabilities can identify and successfully interact with it. This is done through roles that define the structure of the document or application, or through aria-* attributes defining a widget-role, relationship, state, or property.
ARIA use is recommended in the specifications to make HTML5 applications more accessible. When using semantic HTML5 elements, you should set their corresponding role.
And see this you tube video for ARIA live.

What's the key difference between HTML 4 and HTML 5?

What are the key differences between HTML4 and HTML5 draft?
Please keep the answers related to changed syntax and added/removed html elements.
HTML5 has several goals which differentiate it from HTML4.
Consistency in Handling Malformed Documents
The primary one is consistent, defined error handling. As you know, HTML purposely supports 'tag soup', or the ability to write malformed code and have it corrected into a valid document. The problem is that the rules for doing this aren't written down anywhere. When a new browser vendor wants to enter the market, they just have to test malformed documents in various browsers (especially IE) and reverse-engineer their error handling. If they don't, then many pages won't display correctly (estimates place roughly 90% of pages on the net as being at least somewhat malformed).
So, HTML5 is attempting to discover and codify this error handling, so that browser developers can all standardize and greatly reduce the time and money required to display things consistently. As well, long in the future after HTML has died as a document format, historians may still want to read our documents, and having a completely defined parsing algorithm will greatly aid this.
Better Web Application Features
The secondary goal of HTML5 is to develop the ability of the browser to be an application platform, via HTML, CSS, and Javascript. Many elements have been added directly to the language that are currently (in HTML4) Flash or JS-based hacks, such as <canvas>, <video>, and <audio>. Useful things such as Local Storage (a js-accessible browser-built-in key-value database, for storing information beyond what cookies can hold), new input types such as date for which the browser can expose easy user interface (so that we don't have to use our js-based calendar date-pickers), and browser-supported form validation will make developing web applications much simpler for the developers, and make them much faster for the users (since many things will be supported natively, rather than hacked in via javascript).
Improved Element Semantics
There are many other smaller efforts taking place in HTML5, such as better-defined semantic roles for existing elements (<strong> and <em> now actually mean something different, and even <b> and <i> have vague semantics that should work well when parsing legacy documents) and adding new elements with useful semantics - <article>, <section>, <header>, <aside>, and <nav> should replace the majority of <div>s used on a web page, making your pages a bit more semantic, but more importantly, easier to read. No more painful scanning to see just what that random </div> is closing - instead you'll have an obvious </header>, or </article>, making the structure of your document much more intuitive.
From Wikipedia:
New parsing rules oriented towards flexible parsing and compatibility
New elements – section, video, progress, nav, meter, time, aside, canvas
New input attributes – dates and times, email, url
New attributes – ping, charset, async
Global attributes (that can be applied for every element) – id, tabindex, repeat
Deprecated elements dropped – center, font, strike
HTML5 introduces a number of APIs that help in creating Web applications. These can be used together with the new elements introduced for applications:
An API for playing of video and audio which can be used with the new video and audio elements.
An API that enables offline Web applications.
An API that allows a Web application to register itself for certain protocols or media types.
An editing API in combination with a new global contenteditable attribute.
A drag & drop API in combination with a draggable attribute.
An API that exposes the history and allows pages to add to it to prevent breaking the back button.
You'll want to check HTML5 Differences from HTML4: W3C Working Group Note 9 December 2014 for the complete differences. There are many new elements and element attributes. Some elements were removed and others have different semantic value than before.
There are also APIs defined, such as the use of canvas, to help build the next generation of web apps and make sure implementations are standardized.
You might be interested in this list of HTML5 elements and attributes.
Also, please note that it's "HTML 4", not "HTML4". Indeed, for HTML 5, both variants are used, but there is an important difference in meaning. HTML 5 refers to the name of the W3C specification, whereas "HTML5" is the document type of those HTML files with a text/html MIME type that follow this spec.
The same goes for XHTML 5 vs. XHTML5.
Now W3c provides an official difference on their site:
http://www.w3.org/TR/html5-diff/
HTML 5 invites you give add a lot of semantic value to your code. What's more, there are natives solution to embed multimedia content.
The rest is important, but it's more technical sugar that will save you from doing the same stuff with a client programming language.
In short it is much simple compared to html, the long doctype is removed and also center and font tag is removed.
I also answered this difference in my blog :
http://ravisinghblog.in/key-difference-between-html-and-html-5/