While not specifically an Atlas question it is one that I would like to know and understand a little bit more about. How does Atlas handle Accessibility (Section508) types of issues? What happens with screen readers when the results from an Atlas application update UI elements?Using something like Atlas does not meet accessibility standards. To meet accessibility you can only use javascript to enhance functionality. It cannot be the only source of functionality. You need to write pages assuming that javascript is not available.
There are different levels of accessibility. The strictest levels (which very few applications are able to reach) prohibit javascript entirely. More pragmatic levels authorize the use of javascript. Script can even make a site more accessible for example by providing better keyboard access than is possible using plain HTML. Screen readers actually have few problems with javascript sites as long as they don't unexpectedly pop out things without the user's consent.
Accessibility will be a key goal for Atlas. The current bits are very early and may not show that very clearly, but if you look at the hoverBehavior for example, you'll see a place where Atlas already makes it easier to write accessible sites. If you use the hover behavior, the actions that you attach to the behavior will be triggered if the mouse hovers over the elementor if the focus is transmitted to that element. That means that in one simple operation, you've made the control accessible whereas it would have taken about four HTML events to get the same results without Atlas.
For those of you didn't know who I am: I am the author of the Ajax.NET and Ajax.NET Professional library. The library is doing the same JSON formatting like the Atlas Framework is doing. I think I have it already online since March this year, and the feedback I got was great.
If I look in my weblogs (per month about 20 GB without the AJAX requests) I see that there is very small count of users that are not able to run AJAX (and JavaScript) related web sites. Is your web page viewable in an lynx browser? I think there will be a change in the future. Currently we have a lot of web pages that only display news or product information. Other web sites are working as web applications, more UI elements. Those applications will use AJAX in the future to get the most from the browsers. The users of such applications will have by default installed current browsers. So, I do not see any problem to have web applications running JavaScript.
The more big problem is on Internet Explorer that users can deactivate secure ActiveX controls that are needed to run AJAX web applications. I have written a blog about how to use IFrames instead of the Microsoft.XMLHTPP object:http://weblogs.asp.net/mschwarz/archive/2005/08/24/423495.aspx.
As I heared already here at the PDC the next Internet Explorer will have a built-in object like Firefox or Mozilla browsers have today.
Does this mean Atlas will eventually output correct XHTML 1.0 Transitional or will it still be XML based?
It is good that this will work in a large range of browsers, but verybad if it requires XML on the markup page. I would prefer to see markupthat ;meets W3C specifications. This could easily be done by the use ofthe class property and still retain all the same features as presentlydemonstrated, yet also add a host of additional capabilities, includingaccessibility features.
Our corporate firewall for 65000+ desktops strips all XML content, aswell as defanging all references to ActiveX objects, including XMLHTTPobject.
John Davidson
Interesting idea, John. In the classic tradition of community driven involvement, may I ask you to provide a small snippet of the kind of syntax you have in mind. I think I understand your suggestion but I want to be certain. Seeing a sample of the kind of syntax you would prefer would help a lot. THANKS.
It should be pointed out that an Atlas page that's correctly written is XHTML-compliant and meets W3C specifications. The X in XHTML stands for eXtensible, and the Atlas markup is just an extension that is understood by the Atlas script library.
I am using a Atlas quickstart sample for deomonstration from:
http://atlas.asp.net/quickstart/atlas/samples/data/itemview.aspx
The section of code I have concerns with from that page are:
<script type="text/xml-script">
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
<components>
<dataSource id="dataSource" serviceURL="SampleDataService.asmx"/>
<itemView targetElement="detailsView">
<bindings>
<binding dataContext="dataSource" dataPath="data" property="data"/>
<binding dataContext="dataSource" dataPath="isReady" property="enabled"/>
</bindings>
<itemTemplate>
<template layoutElement="detailsTemplate">
<textBox targetElement="nameField">
<bindings>
<binding dataPath="Name" property="text" direction="InOut"/>
</bindings>
</textBox>
<textBox targetElement="descriptionField">
<bindings>
<binding dataPath="Description" property="text" direction="InOut"/>
</bindings>
</textBox>
</template>
</itemTemplate>
</itemView>
<button targetElement="previousButton">
<bindings>
<binding dataContext="detailsView" dataPath="canMovePrevious" property="enabled"/>
</bindings>
<click>
<invokeMethod target="detailsView" method="movePrevious" />
</click>
</button>
.
.
.
</components>
</page>
</script>
The way I would like to see this output is that render elements are defined with the appropriate xhmtl tag that is already defined. Non-render elements would use the <div> tag if they had no additional properties beyond the class name or for single properties and the <input type="hidden" ... /> tag would be used for those non-render elements with additional properties.
<div class="page">
<div class="components">
<input type="hidden" id="dataSource" value="SampleDataService.asmx" />
<div class="itemView" id="detailsView">
<div class="bindings">
<div class="binding">
<input type="hidden" class="dataContext" value="dataSource" />
<input type="hidden" class="dataPath" value="data" />
<input type="hidden" class="property" value="data" />
</div>
<div class="binding">
<input type="hidden" class="dataContext" value="dataSource" />
<input type="hidden" class="dataPath" value="isReady" />
<input type="hidden" class="property" value="enabled" />
</div>
</div>
<div class="itemTemplate">
<div class="textbox">
<input type="text" id="nameField" />
<div class="template" id="detailsTemplate">
<div class="bindings">
<div class="binding">
<input type="hidden" class="dataPath" value="isReady" />
<input type="hidden" class="property" value="enabled" />
<input type="hidden" class="direction" value="InOut" />
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="button">
<input type="submit" class="previousButton" id="previousButton" />
<div class="bindings">
<div class="binding">
<input type="hidden" class="dataContext" value="detailsView" />
<input type="hidden" class="dataPath" value="canMovePrevious" />
<input type="hidden" class="property" value="enabled" />
</div>
<div>
<div class="click">
<div class="invokeMethod">
<input type="hidden" class="target" value="detailsView" />
<input type="hidden" class="method" value="movePrevious" />
</div>
</div>
</div>
.
.
.
</div>
</div>
The above sample syntax should demonstrate that it is possible to cover all elements that you require with Atlas within the standard. Generate this code from within visual Studio would be no more difficult than emitting the XML. The changes to the Atlas XMLDOM parser would also be minimal as all keywords are retained in correct heirarchy and keywords are all found in the class property now rather than as an XML element identifier.
I hope this adequately demonstrates what I was trying to get at.
John Davidson
To be clear the use of xmlns extensions is not conforming with the standard, but is allowed.
From the specification at:http://www.w3.org/TR/xhtml1/#xhtml
3.1.2. Using XHTML with other namespaces
The XHTML namespace may be used with other XML namespaces as per [XMLNS], although such documents are not strictly conforming XHTML 1.0 documents as defined above. Work by W3C is addressing ways to specify conformance for documents involving multiple namespaces.
The W3C document at:http://www.w3.org/TR/xhtml-modularization/xhtml-modularization.html
defines the proper method for using the extensibility features of XHTML. Atlas does not conform to these requirements (yet).
John Davidson
John, can you clarify why you claim its not conforming? Obviously we want to make sure we're not getting in the way of creating valid xhtml documents.
<script> is a standard tag introduced by the scripting module. The contents of script could be anything depending on its type (i.e. content type). If its text/javascript, the expected content is javascript code.
If its text/xml-script, its xml. The content of the script tag isn't dicatated by xhtml I think - its dictated by the type attribute on the script tag.
Note that like the w3c doc says, the <script> tag can in fact be placed in the head section if you choose to do so.
 jwd wrote: |
|
The way I would like to see this output is that render elements are defined with the appropriate xhmtl tag that is already defined. Non-render elements would use the <div> tag if they had no additional properties beyond the class name or for single properties and the <input type="hidden" ... /> tag would be used for those non-render elements with additional properties.
|
First of all, like Nikhil says, the atlas tags should not get in your way to conform to xhtml standards (or any other standard), since the atlas tags are placed inside script tags. If they were part of the actual document (ie. a div containing the atlas tags), then I would certainly understand your concerns.
Secondly, I personally don't like your suggested alternative. You are (mis)using existing xhtml objects (elements/attributes) to describe completely different semantics. Additionally, such an approach could break many applications as well. Using a stylesheet class to define that a div is actually a container for atlas components as opposed to a visual division could break applications that already define styles with names such as "page".
This approach is also kind of limiting. As you can see, you have to be more verbose in several cases. For example, to define a binding you are using several input tags, while Atlas provides a Binding component where you can do the same with just 1 tag and a few attributes.
It is great to suggest alternatives, but I think it is not reasonable to reuse existing tags and 1) limit yourself and 2) change their semantics.
![Smile [:)]](http://pics.10026.com/?src=/emoticons/emotion-1.gif)
HaoK:![Wink [;)]](http://pics.10026.com/?src=/emoticons/emotion-5.gif)
![Cool [cool]](http://pics.10026.com/?src=/emoticons/emotion-11.gif)
I love Atlas more everyday...