Monday, April 18, 2011

Advertising agencies, digital agencies, web developers & printers - you need to understand government's online requirements

It has been an interesting experience working with advertising and digital agencies, web developers and printers while in government - particularly having been on the other side myself for more than ten years.

While some are very good, others definitely 'need development' - particularly in the web delivery space.

Government has a number of requirements for websites and other online properties, however it sometimes appears that these are not always well understood by service providers - or maybe it is simply that some may occasionally seek to 'cut corners' on quality to increase profit margins.
 Service providers are expect to know the mandatory government web requirements when responding to government tenders. As AGIMO states in the WebGuide:
Service providers should be familiar with the Mandatory Requirements and the other guidance provided by the Web Guide when responding to Australian Government tender processes for relevant services.
Below is a list of things that service providers really, really need to know when building Australian Government websites:
  • Complying with WCAG's accessibility minimums is a mandatory requirement for government
    I've been told by supposedly experienced (private sector) web developers that the Disability Discrimination Act 1992 doesn't apply to government, and that it is optional for governments to meet WCAG requirements as it is a 'non binding international agreement'.
    I've also been told by web developers that they won't implement some accessibility features because they 'believe the site is accessible enough already' - despite not meeting WCAG standards.
  • A scanned document turned into a PDF isn't accessible under WCAG 2.0
    Telling me that a scanned document - essentially an image - is accessible to screenreaders if it is converted to PDF doesn't communicate that you're a 'web professional with more than 10 years experience'.
    A Microsoft Word document or InDesign file converted to a PDF also won't meet the Australian Government's minimum standards.
    When you provide PDFs to government, if you are not also providing the content in an alternative accessible format, you will often not meet your contractual requirements.
  • You must include a privacy statement, disclaimer and appropriate copyright notices on government websites
    Telling government staff that a 'Website privacy policy is only necessary if you're collecting email addresses or other information online' is incorrect and creates significant risk for your client.

  • Government Departments can use social media channels
    There is no stricture forbidding Government agencies from using social media channels for communication or engagement activities. In fact many already do - and often in more advanced ways than the private sector.
    There's also no 'conclusive study showing that Australians don't want to associate with agencies or government campaigns via social media channels'.
    There's also limited need for government to engage 'social media experts' who don't understand how to use social media services - such as having a Twitter account that doesn't use hashtags or retweet others or writing a Facebook strategy that just lists the standard Tabs and doesn't provide evidence of expertise in using 3rd party applications or iframes to customise a Page.

    Having an account illustrates you're aware of a channel, using the account well demonstrates your expertise.
  • Building a fake persona on a social media channel then revealing it as fake and a government promotion can be considered false and misleading practice
    Suggesting to a government agency that they should create fake personas and interact as though they were real, build a following or trusting friends and then unveiling the activity as a campaign at the end isn't good advice to provide any organisation.
    Sure there's LonelyGirl and the Jacket Girl, and several other instances of actors used to create fake personas - but never by government agencies. Providing the truth is important in government campaigns and being authentic is important to build trust and respect online. Creating fake personas usually isn't conducive to these and can also break the acceptable usage terms of services such as Facebook (which you should read).
Finally here's some tips - collected from discussions with my peers across a range of government agencies and jurisdictions:
  • We don't need you to build us a CMS and we don't want to finance the creation of your own 'you-beaut' in-house CMS and then pay you every time we need it upgraded. Consider building expertise in an off-the-shelf product - particularly an open source platform with global support.
  • Frontpage doesn't qualifies as a modern web development tool used by experienced professionals. It also leaves code in your pages if you don't edit it out (caught!)
  • We do often notice when you copy code and leave the original author's name and credentials in the (web page) source without appropriately compensating or crediting them.
  • Everyone knows that designers love arty fonts, but if the government agency doesn't own the rights to them they can't use them. 
  • Making all the text links in a website into images isn't a good idea - it makes them inaccessible!
  • Audience usability testing should almost always be a required step in web design. Even if your random sample of three staff really liked the design and could use the functionality, what does the website's audience think?
  • Background music is never acceptable in a website. Self-playing video is only acceptable where there's accessible alternatives and the video can be controlled by the user.
  • Government agencies don't want to pay for your custom reporting system that only you can access so you can give us interpreted results for web traffic. Use a standard web-based platform and give the agency access to the reports.
  • Don't tell agencies it will cost $5,000 per month to host a small government website via your ISP. Particularly when their website lists their prices (up to $30 per month) - oops!
  • When a government agency asks for an email newsletter system with double opt-in subscription, bounce detection, automated unsubscribe, open and click-through reporting, simply using a web-form to collect email addresses and sending emails via Outlook is not a quality outcome.
  • When asked to design a website for an agency to implement in-house, don't provide code or custom functionality that can't be used or build on the agency's platform.
  • It doesn't cost $10,000 to add a share button / reporting system / embed a YouTube video into the website - particularly when the agency is providing all the code for you.
  • You're not a 'Government 2.0 pioneer' if you've never heard of the Gov 2.0 Taskforce, the eGovernment Resource Centre or this blog. Knowing Obama used social media in his first Presidential campaign no longer earns brownie points.
  • Even if this is 'the first time' a government agency has asked you to make a website or PDF accessible to WCAG 2.0 standards, that doesn't mean that your previous standard will meet current government needs.
  • Just because your contact in government hasn't had previous experience developing websites doesn't mean they aren't supported by people who have a lot of experience.
Any other gems out there that people are prepared to share?

7 comments:

  1. Very much with my 'agency hat' on, thoughts on some of the points you've raised:

    * Agencies should expect to be called out if they're not 100% across AGIMO's web guidelines - ergo, those engaging the agency need to be fluent in those requirements too.

    * The old build bespoke or off-the-shelf CMS/CRM/XYZ web app discussion - this is very much tied to how the requirements are put forward. Indicate if you're open to customising an existing app, and suss out each respondent's solution during the pitch - using *scenarios* (joint digital agency celebrations once RFTs move away from requirements matrices to user stories/scenarios!)

    * Usability analysis, should precede implementation & usability testing. Unsurprisingly, a fragmented approach will result in a fragmented solution ;) don't put out multiple RFTs for what should be a holistic, comprehensive project.

    To go back to where the post started, adhering to AGIMO's web guidelines (especially around accessibility) will result in a better overall web project - can't underscore that enough, and I do hope digital agencies who aren't versed in this aspect are challenged!

    ReplyDelete
  2. I think I've lived through every one of these examples as an insider. I've had arguments with agencies over them, as as an external expert brought in to help in recent years, had to undo damage done.

    ReplyDelete
  3. Craig this is a beautiful piece of work - absolutely love it!

    ReplyDelete
  4. Top stuff, let's hope the message gets through! :)

    ReplyDelete
  5. Gold! The other one I can think of is: "Don't be cheeky and try to promote your web company by putting your logo at the bottom of the page, or hidden in the HTML code of the page. We didn't like it 20 years ago when printers tried putting it on our brochures, and we don't like it nowadays."

    ReplyDelete
  6. Thanks Darren - I've seen that too!

    As well as seen a company attempt to claim copyright over the Commonwealth Crest and all the agency information. It was done through a lack of understanding of copyright, not maliciously - but even so...

    ReplyDelete
  7. Very interesting post.. I must say that was worth reading. I love the way you organize the topics. Thanks for sharing it with us.

    ReplyDelete

Note: Only a member of this blog may post a comment.

Bookmark and Share