Frequently Asked Questions

Do I have to comply with every Checkpoint?

These Checkpoints (Guidelines) are specifically designed to ensure all websites and applications published, internally or externally, by DEECD are highly accessible, usable and easy to maintain by DEECD staff.

Some checkpoints might not be applicable to all websites or applications due to variations in technology used and therefore will not be checked against during the Quality Assurance (QA) process (see What is the DEECD QA process?)

It is expected, however, that all requirements listed in the Developer's Resource Kit that are relevant to a particular website or application must be adhered to by web and application developers.

Back to top

What minimum standard do we need to QA against? Is it enough to comply with W3C WCAG Single A level only?

The Australian Law (Section 24 of Disability Discrimination Act 1992  (www.austlii.edu.au/au/legis/cth/consol_act/dda1992264/s24.html)) states it is unlawful to deny access to any information or services.

Compliance with W3C WCAG 1.0 Single-A or even AA levels does not cover all web accessibility problems and therefore is not enough to make a website fully accessible.

Furthermore, the Human Rights and Equal Opportunity Commission (HREOC) recommends "compliance with the W3C WCAG 1.0 guidelines to the Single-A level is a minimum rather than a desirable outcome" (AGIMO  (webpublishing.agimo.gov.au/Accessibility)).

Back to top

What are the DEECD Guidelines and why do I have to adhere to them?

These Guidelines are created to help both internal and external web and application developers to design, build and maintain fully accessible and usable websites to be published by the DEECD. These guidelines cover the following areas:

  • W3C priorities A, AA and some AAA
  • Whole of Victorian Government Web Standards requirements
  • Usability and Accessibility points based on the best practice development strategies that are not covered by the W3C or WoVG (e.g. point concerning printable web pages)
  • Points that facilitate consistency across departmental websites (e.g. appearance of external links)
  • Points concerning handover issues between external contractors and internal staff that facilitate effective maintenance (e.g. readability of HTML, etc)

It is expected that all Guidelines that are relevant to a particular website or application project are followed by the developers to ensure that all published application or web content is of a high quality and is accessible, usable, and consistent across the Department and Whole of Victorian Government and is easy to be maintained by internal staff.

Back to top

What is the DEECD QA process?

All DEECD websites and applications developed both internally and externally will be tested by members of KSCU against the Quality Assurance Checklist (XLS - 145KB), which is based on Web Development Guidelines (see What are the DEECD Guidelines and why do I have to adhere to them?). The majority of the websites and applications will be quality assured against the Core.

You need to contact KSCU Manager to schedule the QA of your application or website.

The size and the complexity of the website or application as well as availability of KSCU staff will determine how long the QA process will take. In general it takes between two and five working days and, therefore, needs to be factored into the project timelines.

Following testing, a QA report will be produced and provided to the business owner of the site/application.

It is a requirement that all DEECD Websites must meet Quality Assurance Checklist points before being released for public viewing.

Back to top

Who can I talk to for any questions regarding any of the points?

If you need assistance with any of the DEECD guidelines please contact KSCU or BSDB.

Back to top

At what stage in the development should I be considering these guidelines?

It is important to ensure that the guidelines are reviewed and factored into the project timelines prior to the commencement of the development as it might be very difficult to fit in any of these requirements in the retrospect.

Back to top