This checklist is intended to provide overall guidance in building and testing applications and websites for the shared environment. You are encouraged to review and complete this document prior to the beginning of application coding. With the exception of applications/sites that must be stress tested, your agency is responsible for determining when the application/website is production ready.
When the application/website is ready to launch please use the Request link to the left to let us know. (http://ohio.gov/portal/feedback.stm)
Status |
Item |
| |
Security |
|
|
Do you require SSL Certificates? - SSL certificates for https encryption are not provided as part of the hosting environment and must be purchased by the customer. The hosting service staff can assist with this process if needed. Certificates generally run about $300.00. Please see the policies on this page http://www.oit.ohio.gov/IGD/policy/OhioITPolicies.aspx. In particular review ITP-F.1 |
|
|
Is personal information to be maintained? If private information such as passwords, license numbers, social security numbers, etc., is collected, be sure to do so in a secure fashion. It is strongly recommended that the statutory authority be identified prior to designing an application which uses social security numbers as identifiers. Please see the policies on this page http://www.oit.ohio.gov/IGD/policy/OhioITPolicies.aspx. In particular review Bulletin ITB-2007.02 |
|
|
Are there any special security requirements? If so, please indicate below.
|
| |
Session State |
|
|
Does the application need to track the user from page to page? If you so, please keep in mind that standard asp session variables will NOT work in a load balanced environment. Session info can be maintained in one of three ways: Client cookie, Database content, or dot-net session info on a session-state server. The shared web hosting service does include a session-state server. |
|
|
Are Client Cookies to be used? If you so, please keep in mind that general policy discourages the use of permanent cookies. |
|
|
Are there any special Session State requirements? If so, please indicate below.
|
| |
Database |
|
|
What database is to be used?
Both MS Access and SQL Server are supported but this check list and a global.asa for database connectivity are required prior to launch.
|
|
|
Is the application Read only or Write enabled?
Write enabled MS-Access can only accept data on ONE server of the balanced environment. Application coding for MS-Access write-enabled databases MUST be done so that the portion of the code that writes to the database is in a transaction page that is called from an application page and then passes results to a response page. Do not create write enabled MS-Access applications with all coding in a single recursive page.
|
|
|
Where will the data reside?
For MS-Access databases DataRead and DataWrite directories have been set up to house database files so that they can not be downloaded from the website. This protects the data. MS-Access files must be developed within the Agency and tested in the shared web hosting environment prior to production launch. A SQL Server test and production enviornment is provided for Agency use. However, the Agency must provide an in house development environment.
|
|
|
Global.asa files are required for connectivity.
ODBC connectivity is NOT supported. All connections must use OLE-DB utilizing a global.asa file or a .Net Config file to establish an application variable for the connection string. As part of this process the application will be set up to run in its own memory space and isolated from other applications and sites. Although general database connectivity is made through an Application Variable, connectivity that is specific to the user will require Session State.
New global.asa files will NOT work unless an application object is created by the hosting staff. Use the request link in the left navigation to request that an application object be created for your application directory. Global.asa files should NOT be nested.
|
|
|
Specific directory required for applicaitons
Application code must exist within a subdirectory of the agency folder in the shared web hosting environment. The application code must have a default page that will run when the domain and directory name are used as the URL and the file name is NOT included. Special file names for the default page are NOT supported. It is strongly recommended that the agency use a default page named Index or Default with extensions of htm, stm, asp, or aspx as a redirect to the actual home page of the application. This enables the agency to control application availability as needed by uploading a maintenance page with the same default page name.
|
|
|
Are there any special Session State requirements? If so, please indicate below.
|
| |
Database Searching and/or Updates |
|
|
Have the fields available for use as search criteria been fully identified? All fields that are to be used as search criteria must have an index. Full table scans are prohibited. Use wildcards in searching with care. As a general rule attempt to limit results sets to 200 records or less and keep table joins to 3 tables or less. It is recommended that all Insert, Delete and Select SQL be identified prior to the start of application coding. |
|
|
Have the fields that will allow wildcards in search criteria been fully identified? All input and search fields must have validation at both the client and server level. Validation must be such that SQL Injection is prevented. Full table scans are prohibited. Use wildcards in searching with care. As a general rule attempt to limit results sets to 200 records or less. |
|
|
Will you want to do Load Testing? If so, see load testing scripts. If anticipated load exceeds 10,000 visits per day load testing will be required prior to launch. |
| |
Miscellaneous |
|
|
Does the application require any special tools, e.g. file uploading, email, spell checking, etc.
|
| |
Review for accessibility compliance (W3C Content Accessibility Guidelines 1.0, 508 requirements) Please see the policies on this page http://www.oit.ohio.gov/IGD/policy/OhioITPolicies.aspx. In particular review ITP-F.3 |
|
|
Text Equivalents - Provide a text equivalent for every non-text element (e.g., via ”alt”, ”longdesc”, or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
- Provide redundant text links for each active region of a server-side image map.
- Provide an auditory description of the important information of the visual track of a multimedia presentation
- For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. |
|
|
Use of Color - Ensure that all information conveyed with color is also available without color |
|
|
Natural Language - Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). |
|
|
Create tables that transform gracefully - For data tables, identify row and column headers
- For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. |
|
|
Ensure that pages are accessible even when newer technologies are not supported or are turned off. - Organize documents so they may be read without style sheets
- Ensure that equivalents for dynamic content are updated when the dynamic content changes
- Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. |
|
|
Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped
- avoid causing the screen to flicker
|
|
|
When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided. |
|
|
Use features that enable activation of page elements via a variety of input devices
- Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape
|
|
|
Alternative Pages
If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.
|
|
|
Provide context and orientation information Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret.
- Title each frame to facilitate frame identification and navigation
|
|
|
Use the clearest and simplest language appropriate for a site's content.
|
|
|
Additional 508 requirements
- When electronic forms are designed to be completed on-line, the form shall allow people using assertive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
- A method shall be provided that permits users to skip repetitive navigation links.
- When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
|