WCAG 2.0 and ATAG together - accessibility

I am bit confused about ATAG and WCAG 2.0.
I was wondering if it is ever appropriate to use both ATAG and WCAG for one system?

WCAG provides guidelines for Web content: How can I make my Web content accessible?
ATAG provides guidelines for Web authoring tools: How can I make my Web authoring tool accessible, and how can I make sure that it produces accessible content?
ATAG relies on and references guidelines from WCAG. So whenever you need ATAG, you’ll most likely also need WCAG.
Related page from the Web Accessibility Initiative (WAI): Essential Components of Web Accessibility

ATAG stands for Authoring Tool Accessibility Guidelines. They provide guidelines for DESIGNING web content authoring tools that are both more accessible to authors with disabilities and designed to enable, support, and promote the production of more accessible web content by all authors. ATAG applies to Content Management System (CMS), any website which you can create content or the admin section of your website.
WCAG stands for Web Content Accessibility Guidelines. It covers a wide range of recommendations for making Web content more accessible. WCAG applies to any web content on a website.

Related

HTTP/2 with WebForms - What actually does this feature mean to a developer?

I am exploring the current news for ASP.NET WinForms with .NET 4.6.
The resources I am currently looking at is this Video overview by Microsoft Program Manager Pranav Rastogi and an article on DotNetCurry. Besides the information, that I will require Windows 10 Preview, I can not decipher, what this really means to me as a WebForms developer.
To use HTTP/2 will I...
need to make some changes in a config file?
need to change something in the page / master page?
use a different programming model when it comes to serve resources?
Of course, IIS will need to be configured, but this does not affect me as developer.
Is there actually something I need / can do as developer to support HTTP/2?
Note: If someone sees this as a better fit on Programmers or other SE site, please move.
Basically, HTTP/2 is seemless for web services. The basic functions, request/response multiplexing and header compression, are defined at the network protocol level. That means it can be seen as the matter of web browsers and web servers.
But for the new features like HTTP/2 server push and stream priority/dependency, it needs to be considered for developers. To use those features, web browsers and web servers should provide APIs.

Good replacement of GWT for asp.net

I know Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. GWT is used by many products at Google, including Google Wave and Google AdWords. It's open source, completely free, and used by thousands of developers around the world.
It can be integrated in java based web applications....
Is there any suitable replacement of GWT for asp.net web application?
If so,what is it?
GWT is platform agnostic. It can be easily integrated with any web application, not just Java. You just tell it to inject widgets into elements on the host page - the host page could be static HTML.
The built in RPC mechanism makes it easy to do RPC with a Java on the server side, but you can certainly use JSON or XML to exchange data with your server. It's a little more work, but not impossible. Look up 'overlay types' - these make working with JSON data extremely easy.
Consider SmartGWT. It has a built-in REST connector that is easy to connect to REST services on the .NET platform, which Visual Studio can help you generate.
On the .NET platform, the free open source (LGPL) edition is all you need. If you need commercial license terms, those are available too.
Take a look at Script#, but I'm not sure if it's still in development. "Essentially the Script# compiler is a C# compiler that generates Javascript instead of IL."
http://www.nikhilk.net/Entry.aspx?id=121
If you're just looking to hook up an ASP.net web application with GWT, try
GWT and .NET

Implementing document management with an ASP.NET MVC front-end

I've implemented a website for a client that holds editable articles.
I used ASP.NET MVC and made the content manageable by storing it in a 'Content' table in the database and creating a simple Admin section of the site, where the user can add/edit/remove content and choose where on the site it will appear.
Now the client has come back wanting full document management features. They want version control, permissions, PDF export and simple workflow on all content items.
I'm debating in my head how to do this.
I found one question where a lot of people recommended WSS (Windows Sharepoint Services).
The thing is, I want to build the admin interface myself and make it really easy for the client to use.
Will WSS allow me to do this?
WSS has functionality for storing and versioning of documents, and workflow.
I don't think that PDF conversion is not part of WSS, but you could use a 3rd party tool.
You could use the WSS UI for the Admin site, placing documents in spesific document libraries. But for your ASP.NET MVC site you could access WSS via web services (WCF).

Difference between Web Application Framework and a Content Management System?

Are both completely different concepts? Or is there an overlap in their meaning?
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
Are both completely different concepts? Or is their an overlap in their meaning?
A web (application) framework is a lower level, generic toolkit for the development of web applications. That could be any type of system managing and processing data while exposing it's data and services to human users(via web browsers and other interactive clients) as well as machines via the http protocol.
A CMS is one type of such applications: a system to manage content shown in websites. Usually/historically, this mainly means managing (pieces of) text of "pages" shown in a web site, and useres that have different levels of access to manage this content. That's where the C and the M come from.
With a CMS, you can manage web content. With a Web framework, you build web applications.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
No. It would be correct to say that a web framework can be used to create a CMS.
Both contain parts that work on the backend as well as on the front end.
Often, a CMS is based on a web framework - sometimes CMS developers build there own web framework, and sometimes they even expose the API of this framework, so a developer can create extensions to the CMS in a way as if he would develop an application with a web framework. Drupal really does this, so you can create real web applications based on the integrated framework - with the upside that they will also be easily to integrate into the CMS.
But that(exposing the API of a web framework) is no necessary criteria for being called a CMS.
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
It's be possible to combine two existing systems build with these two, (e.g. because you want to show some data in a web site managed by drupal, that already exists in a Rails-based system).
But as Drupal also provides you some of the genric functionality of it's underlying web framework, it might not be necessary. You would have to manage and learn two very different systems and handle all the problems with there interoperation. So, I'd try to build a Website with only one of these if possible and only combine them if theres a good reason to.
They're different concepts. A CMS can be built on top of a web-app framework, but a web-app framework has no direct relationship to a CMS. Its at a lower level, providing a platform for any type of web-app to be built on top of it, of which a CMS is an example.
Drupal runs on php and Ruby on rails runs on, well, Ruby, so they wouldn't play together.
Just to muddy the waters a bit, Drupal describes itself as a content managment framework which is essentially a content management system with hooks to extend it. Which does create an overlap. The drupal overview describes this better than I could.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
It's not "correct" but it's not wrong, either. A web framework is a general concept -- many things count. A CMS is a specific concept, often built within a web framework. Sometimes CMS's are stand-alone web applications. More often, however a CMS is a back-end things that require a customized presentation front-end.
Should the Web Framework use the same technology as the CMS?
Shouldn't matter. At the end of the API definition, the Framework and CMS can have any implementation at all.
Web App Frameworks -- generally -- must either serve HTTP requests or plug into something like Apache.
A CMS is a glorified database, and any sensible API is good. Most often, however, they're also using HTTP as their interface protocol.
Could Ruby on Rails be used in combination with Drupal?
Sure. Purists will object, but there's no technical reason why they can't cooperate.

Are ASP.NET Web Parts a viable technology for implementing a portal architecture

Web parts seem to be used extensively in Sharepoint related development, but examples of using them in asp.net webforms applications are few and far between. I'm implementing a domain specific portal framework and like the "widgetlike" functionality in iGoogle or pageflakes and would like to get that kind of feature in my application. The real troubling issue from my perspective is that the drag & drop layout features of web parts do not work in non-IE browsers unless you use the latest ASP.NET AJAX futures library. It seems to me if Microsoft meant this to be a foundation technology, they would have moved these features into the main product by now.
Are web parts a dead-end technology? If so, are there any alternatives?
i think they are (dead), at least for developing the types of UI modern web-browsers are looking for. My recommendation ... ASP.NET MVC and a nice .js library. It's more work out of the gate, but with the proper planning and implementation it will serve you much better in the long run.
I found a really great site about some tips to implementing WebParts-like behaviour:
http://blogs.msdn.com/b/nunos/archive/2010/02/16/quick-tips-about-asp-net-mvc-webpart-framework.aspx
Webparts are a part of the .NET infrastructure and are a foundation technology. There are few interface technologies, to make webparts compatible with their J2EE counterparts.

Resources