Before Dev

  • Feature list
    • Every piece of page needs to be accounted for, what is editable
  • INDEX current site
    • or look at the /sitemap.xml
  • Questions
    • NO PANELS NO MATTER WHAT!!!! NO MATTER WHAT!!!!! NO MATTER WHAT!!!!! Unless the content/design doesn't matter no content can ever be in a panel. If the client might want to add text, don't do a panel, if the arrangement of the images make a difference don't make a panel, if ANYTHING needs to a certain way, it won't work right in a panel so don't do it.
    • Potential number of users simultaneous vs hourly vs daily vs yearly
    • feature list
    • hours estimate
    • timeline, is there an end date goal?
    • Is there a reason for the deadline, bussniess reasons? Make sure there is a buffer zone
    • Deadline of the approvals, and which deadlines have hard dates.
    • If there is a current site, what are we doing with their urls.
    • Does the client have a google account? (look at accounts bellow)
    • What languages is the site going to be viewed in?
    • Before client upload content, designs need to be done. We then create a system so we can auto upload the content they have collected.
    • What type of design will dev get? Are we doing an iterative process? Will we need more dev time because of prototypes?
    • How data driven is the site? How much of the site is content dependent, highlight areas of the site that will fully depend on content type.
    • What legal items need to be done before the site can go live, copy right? legal departments?
    • What Policy pages will they need! THIS NEEDS TO BE INCLUDED ON THE SITE MAP.
    • Is there anything that is innovative in this project that we could apply to sr'end
    • IS there anything above and beyond what the client is asking for that would be applicable to sr'end
    • For 500 page errors who should be notified on your end, does it matter if client facing we have our email?
    • What level of accessibility compliance does the project need to match? wcag?
    • Do we have a modal Design?
    • Ordering of data?


  • what accounts are being used
  • access to previous accounts
  • Analytics
  • webmaster tools
  • Google account MAPS API billing
  • AWS account for hosting
  • DNS login
  • Their current account logins for their current site

Previous Domains

  • What pages need redirects
  • what was the robot's txt format

Design Phase 2 talks

  • Follow the wire architecture page/information architecture, make sure every page is seen (or made reference to if generic design)
    • Are any pages missing (404 and 500)
    • Is there missing links to pages?
    • Is the goal of each page achieved?
  • PRINT out the invision, we should be looking at a printed version of the site so we can compare the pages very quickly and easily.
  • THIS is about useability as development, we should do it in 2 phases development mode, and accsibility mode
  • Questions
    • Is there anything that is the full frame that is the fixed size?
    • What happens to full-width sections
    • What is base grid
    • Is there any input fields that require special treatment
    • Is there any input fields without obvious labels associated to them
    • How many items of x products/pages/versions of this section (think how many products are there)
    • Is there any fixed elements with buttons in it? Where does it sit in the stack of tabbin?
    • Where do the links link to
    • Are there any modals? (video? designs for this?)
    • Typefaces, are they web-based?
    • How are the images cropped in Design?
    • Is there a demonstration of poorly cropped images and the client understands that with this design that
    • What devices are going to be used?
    • How are the downloads going to function on all devices?

some times the images won't be cropped nicely?

  • Are we allowed to crop the photos? Are we allowed to crop the photos poorly?
  • Is there any outliers in the data set? In an image gallery is there a really tall image?
  • What areas of the site are data driven, what is the data, do we have the data we can expect/real data?
  • What happens if there is no data? What happens when there is too much data?
  • What happens with a different data sets, what are all the vairables in the data set? (tool A vs tool B )
  • Buttons width are based on content and not grid
  • Is there any text that is smaller than 16pt, if so how secondary is it, can it be so small? Will the text that is being shown there actually be that small?
  • What are the top of elements aligning with? Make sure it's thought about, is it top of the page or just an arbitray ammount, does it have to be the same as something else?
  • What elements are going to be imaged, that the design team can switch out to make work?
  • Review feature list
  • What is the approval process for the client going to look at for each stage?
  • Review content, is all the content on the site the real content
    • if the content is not not done we can move into dev. (in certain ways)
  • Links, where does every button and link lead to? (be explicit)
  • Has the client seen these designs? Have the proper people reviewed the designs?
  • If the site is content driven, is there multiple versions of the same content?
  • What does the page look fully open (all the sub sections showing what content they have in them)
  • Brand audit, is this fitting in with their brand?

* Question Dev

  • What do client facing emails look like?
  • What email is sending these emails?

*Features requested after design or during design that are software features should be noted in the Approved PDF that is sent to DEVELOPMENT.

Hand off

  • DEAD LINES? What is the expectation? --- this should already be known
  • What is the deadline for content?
  • Client has signed off on designs
  • There is mobile designs
  • Go through the site, pdf making sure to hit up every page
  • Give Hex of all colours used
  • Give all image assets (logos, images)
  • Give all SVG assets
  • Create all sign off forms: Click through, Beta site.
  • Create spreadsheets of all content that the client has/will fill out or has this already been made?
  • In the designs what info is true and false, can we take any info from the designs?

Client Hand off

Timeline Creation

  • Make an issue tracking list
  • Contain every page including backend
  • 4 days before deadline have check-in if it's going to be meet
  • Every task/page should have total number of hours needed (overestimate) - these hours are initial hours, then there are revisions after that are not included in the hours

Redict Map for existing sites

1. Gather

Obtain a list of all the revamped URLs for the new site design. At the same time, develop a full list of all the original URLs from the old site. Your developers may be able to provide these lists, or you can assemble them using a crawling app. I used Integrity for Mac; Screaming Frog works, too.

2. Compare

Place the two lists side by side in a single Excel sheet.

3. Map

Now, match each old URL with its corresponding new URL. For the most part, this is going to be a fairly straightforward process. It will be obvious, for example, that the “About Us” page on the old site is going to redirect to the “About Us” page on the new site, etc.

Some pages won’t be so obvious, and you’ll have to make your best guess for where to redirect it. Using filtering rules in Excel, you can find common words in the URLs, and automatically match old ones to the new.

(Note: For sites with millions of pages, automating the process is essential.)

Content Spreadsheet

  • Separate spreadsheet for general content vs content that will be may of (items/blog/articles). Even list of logos should be a separate sheet/page of the spread sheet.
  • How consistent does the data need to be
  • Are we going to be using this data to programmatically do anything
  • Will this field of data be used in multiple places on the site, is there a preview text?
  • What is the cut off date for uploading content to the sheet?
  • What is the meta data like? What content are we using for each page? (when you share the page on face book what content shows up)?
  • What are the social links like (when you click the twitter icon)?

Email Client

  • Tell them Dev is taking over "taking over the process" must be stated so that all responsibility is pushed on to Dev now
  • Dev emails back setting up phone call with click through of site

Hi <Client>, A pleasure to meet you. I’ll be taking on the development stage and working with you until project completion. It would be great to have a phone call with you this week in order to go over the details and next steps. I’m available <TIMES>. Let me know what works best for you. Cheers,


  • talk about process 4 stages
    • Define what is changed at each stage
    • As we go through each stage changes become smaller
    • Talk about consequences of wanting changes
  • walk them through the click through

Dev follow up email

  • Have a gant link
  • Explanation of each phase

 1. Click through (where we are now), we are looking to address that the site makes sense as a whole. Style is basically none, and it is functional to a point where we can navigate the site. 2. Alpha version of the site, at this step we have started to add styles and images to the site. All of the functionality is working and is being tested for bugs. The mobile version of the site is not taken into account usually. 3. Beta version of the site, the difference between this and live site is very little, we are addressing the details and edge cases. 4. Deployment of the live site, after this we give support for a month to catch any bugs and fix them within a week.

Click Through

Basic HTML

  • Use information architecture to create this!!!! not the wire frames (only after first pass is done).
  • Set up base files for everything
  • Create all the pages with nav and click through
  • Very basic content

w3 accessibility

Google accessibility


  • Feature list
  • test any new js
  • test css features


  • deploy to a port

Feed back internal

  • Feed back needed before we send it out
  • Feature list, anything missing?
  • Are all the pages we need in the website
  • Is the way the user will navigate through the site simulated (all the links are there)
  • Is the HTML structure correct, HTML, h1,h2,buttons,a...

Feed back external

  • Feature list, anything missing?
  • Does the site seem to be missing any pages you where expecting?
  • When you go through the site can you navigate through the site the way you where expecting to?
  • Please note there is no image, the aesthetics of the page are basic.



  • what is the core functionality
  • what is the secondary functionality
  • what do we need to move this into a beta?

Basic CSS

  • Set up font
  • Set up Colours
  • Set up base font size
  • Set up h1,h2,h3,h4,p,a,buttons,block quotes,ul
  • Set up wrapper if there is one
  • Set up grid if there is one (might be too basic)


  • enter all text
  • enter all images and svgs

w3 accessibility

Google accessibility


  • deploy to a port



  • review the site - is there any assets still missing?

ADD specific css

  • adding blocking (blocking being widths and positioning)


  • Add js functionality
  • Add external functionality (mail chimp)


  • Add details special styles


  • IE 9 - most modern
  • Safari
  • Firefox window
  • Firefox mac
  • Chrome windows
  • Chrome mac


deploy on dev.<client url>

  • click through every page


  • content review
  • Let client know that URLs for login changed


Unless the client needs special ssl keys for extra security we should just be using lets encrypt, in combonation with this bot running cron jobs to keep the server uptodate.

POST Launch

  • Web master tools
  • Add to cal 1 month support
  • Do we have a multi year support setup/hosting for them?
  • Add the date of the launch
  • A week before 1 month is up to given them notice that their site is no longer supported

Best Practices


CASL compliance

  • Yslow ( install the app )

w3 accessibility

Google accessibility

w3 accessibility

Google accessibility


Testing with Voiceover


Set up Gtag mananger Set up Demographics

Accessibility Checklist

  1. Make sure your HTML is as semantically correct as possible. Validating it is a good start, as is using an Auditing tool.
  2. Check that your content makes sense when the CSS is turned off.
  3. Make sure your functionality is keyboard accessible. Test using Tab, Return/Enter, etc.
  4. Make sure your non-text content has text alternatives. an Auditing tool is good for catching such problems.
  5. Make sure your site's color contrast is acceptable, using a suitable checking tool.
  6. Make sure hidden content is visible by screenreaders.

Make sure that functionality is usable without JavaScript whenever possible.

  1. Use ARIA to improve accessibility where appropriate.
  2. Run your site through an Auditing tool.
  3. Test it with a screenreader.
  4. Include an accessibility policy/statement somewhere findable on your site to say what you did.


mozilla, html 5 structure

test the structure of the site

wordpress standards


WAI-ARIA BasicsSimple Website Example using ARIA roles

3 Main Features

  • Some describe different page structures, commonly found in UIs
    1. role=“banner”
    2. role=“search”
    3. role=“tabgroup”
    4. role=“tab”

Toggle line numbers   1         <nav>   2         role=“navigation”   3         <aside>   4         role=“complementary”

ROLES: Defines what an element is. Follow the same semantic value of HTML5 structural elements

Toggle line numbers   1         aria-required=“true”   2                 Form input needs to be filled in   3           4         aria-labelledby=“label”   5                 Allows you to put an ID on an element   6                 Then reference  it as being the label for anything else on the page (including multiple elements)

PROPERTIES: Define properties of elements, give extra meaning to semantics

TEXT ALTERNATIVES How to use text alternatives Can also be used as an alternative for image alt text Specify existing info on page using IDs

Toggle line numbers   1 <img src=“image.png” aria-labelledby=“image-label”>   2 <p id=“image-label”> Description of image>

  • Form input is currently disabled


STATES:Special properties that define the current conditions of elements

States have the ability to change throughout the lifecycle of app via JS, whereas Properties cannot change

When to use

1. Signposts / Landmarks Role attribute values can act as landmarks

Replicate semantics of HTML5 elements ie: <nav> Provide signposts to different functional areas ie: search, tab group, tab, listbox, etc.

2. Dynamic content updates

  • off: the default, updates should not be announced polite: updates when user is idle assertive: updates as soon as possible rude: announced straight away, even if it interrupts the user


aria-live:Informs users when an area of content is updated via XMLHttpRequest or DOM APIs How urgently the content is read out depends on the attribute value:

3. Enhancing keyboard accessibility When other HTML elements are used along with JS to simulate similar interactions, this affects keyboard accessibility. When this is unavoidable, in order to give elements focus use tabindex

Making non-focusable code focusable

  • This value allows elements that are not normally accessible via tabs, most useful value of tabindex
  • This allows not normally accessible elements to receive focus programmatically via JS or as the target of links


Keyboard Accessibility

Additional reading on tabindex

4. Accessibility of non-semantic controls


SCSS << tool to index the site