The accessibility scan is there to check the published content of every page on your website. At a global level, you can see all accessibility issues and problems and quickly address them. Generally, if there are any issues, it will be down to template implementation, not the content produced by Contensis itself.
This screenshot shows the Quality Assurance Dashboard; this displays a summary of your overall QA.
The accessibility checker checks level A, AA, and AAA accessibility compliance, and gives you source snippets of where problems occur. Obviously the automated checker cannot check some issues which require human investigation, but it can suggest areas that may need checking.
If you are not familiar with web accessibility the WAI (Web Accessibility Initiative) website is a good starting place.
Contensis will provide you with a platform to ensure that inaccessible content from a technical level will simply not be allowed to be published, if you so desire. But accessibility must be understood internally, and you must ensure design processes and other areas take accessibility into consideration.
It is also worth ensuring that areas that cannot be checked with an automated checker are reviewed regularly.
Accessibility in the WYSIWYG Editor
Many of our competitors have added accessibility tools into their systems as an afterthought. Our guiding principle is that when users are creating content we should guide them down the route of accessibility, without them even realising it.
This screenshot shows the wizard for resolving accessibility issues within the WYSIWYG Editor
You may think that accessibility is not an important issue for you, but it is proven that accessible sites are search engine friendly sites, so even if you don't have legislation, you will probably have the marketing department pushing this issue anyway!
Often systems will let you spend hours creating content and then at the end of creating your page on a Friday afternoon you find out that you need to run through 100 accessibility mistakes and fix them!
We have detailed below some of the ways in which we address accessibility issues whilst editing:
Within the WYSIWYG Editor the system checks the heading orders and will only allow you to add in headers that are appropriate for the place you are editing in the web page. This feature prevents mistakes at the very start of the editing process and will save hours of time if you had to go back and completely re-format a piece of content.
When adding hyperlinks, we ensure that Tool Tips are provided, so that you do not have to go back and add these later. If you drag and drop a hyperlink, the title will automatically be taken from the Content you have chosen.
When images are uploaded into Contensis we push the user through the process of entering ALT text so that we can be assured ALT text is provided on all images that are uploaded.
When users are creating tables, they have the option to specify table summaries and to define heading rows or columns. This is a necessity for providing accessible data tables.
Individual editors can check the spelling in their pages, but what if they forget? What if that last minute news article goes out unchecked?
When the Quality Assurance module checks the site, it scans all the textual data for spelling, and keeps a record of all misspelt words.
This screenshot shows the global dictionary editor - new words can be added globally or, if required, you can remove words that users have incorrectly added.
If a word simply doesn't exist in the dictionary, then with a single click you can add it to the global dictionary, and it will remove the spelling error from all pages that have it.
Often product names and industry specific terms need to be added. Once a library of these is built up, the spell checking becomes a very effective part of the QA, as it will constantly scan for misspelt words, even on non-CMS content such as content that has come from perhaps internal databases or other systems.
The ability to keep a global site-wide tab on your content is imperative.
As the global dictionary is used by the WYSIWYG Editor too, time will be saved by users as more words are added, because, unlike tools such as Word, the custom spell-check words are global; so if one user adds a special term, it will appear correctly for all users.
HTML compliance is a critical factor for almost any site. Some organisations such as local government will be measured on this, but for everyone HTML compliance is imperative, as without it your site will not be as search engine friendly as it could be, and will not load efficiently in modern browsers.
Contensis ensures that whenever your content is published it is fully XHTML compliant; so you may ask why have a checker?
The checker is there to take care of situations that can occur with developers using custom code in templates and developers writing bespoke web controls.
The HTML compliance check will ensure that your site fully meets the current XHTML guidelines.
There are a number of different ways in which links are managed in Contensis. Firstly, we will talk about links between objects in the CMS, for example a link from one page to another.
In this case, the system manages the content of both source and destination, so we know if the target updates at any point and we can then automatically update the source. An example of this may be when we delete a particular page. At the point of delete the user will receive a message indicating that deleting the page will affect x other pages that link to it.
This screenshot shows the screen that appears if you try to delete a page that is linked to from other pages.
This screenshot shows the screen that appears if you try to delete a page that is linked to from other pages; you can instantly see which pages link to the page.
At this point the user can then possibly change their mind or continue to delete it anyway. When the page is deleted, the first action the CMS will undertake is to remove the link from all of the source pages, so that no broken links occur. When all these links are removed, the system will then delete the actual page in question from the relevant servers.
Now we have prevented broken links and successfully deleted the page. At this point the editors will be informed about the page deletion, so they have the chance to either point to a new page or remove the link altogether. They will be notified using the Notification Services .
So, as you can see, a broken link in CMS managed content is near impossible. An area where broken links can occur is either in bespoke code that creates links automatically or in links to external non-managed resources.
In this case the systems sweeps the entire site regularly and assesses if there are any broken links. If there are broken links, the system will remove the links from the page and inform the relevant editors.
In order to check external hyperlinks the system will require internet access.
Tying these two forms of link management together will give you a system that makes it almost impossible to have broken links.
When the QA module scans a page it will investigate the entire size of the page from both a pure HTML perspective and a total size, including all images, CSS and other web resources. Normally you will then define a maximum acceptable page size for your target audience.
If a page goes over this size it will be flagged, or you could simply order pages by size and check some of the larger ones. You can control the metrics used; in an intranet environment you may be less interested in size than on a mobile site, for example.