{"id":1434,"date":"2018-04-27T17:02:26","date_gmt":"2018-04-27T17:02:26","guid":{"rendered":"http:\/\/pressbooks.library.ryerson.ca\/pwaa\/?post_type=chapter&p=1434"},"modified":"2019-08-12T16:21:51","modified_gmt":"2019-08-12T16:21:51","slug":"informal-reviews","status":"publish","type":"chapter","link":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/chapter\/informal-reviews\/","title":{"raw":"Informal Reviews","rendered":"Informal Reviews"},"content":{"raw":"An informal review is a quick scan of a website to identify obvious accessibility issues. While these reviews do not represent exhaustive audits, they are useful for a variety of purposes.\r\n

Purpose of Review<\/h2>\r\nAn informal review is often attached to a quote for a formal accessibility audit, providing some introductory information to a client to give them a better idea of the types of issues on their website before they commit to the formal review. An informal review can be helpful in justifying a formal review.\r\n

Process of Review<\/h2>\r\nInformal reviews often occur as part of a conversation, perhaps with a member of an organization who is responsible for managing an organization\u2019s image, or with a developer who is planning or reviewing design activities. These reviews will often involve a couple of quick tests, like the Tab Key Navigation test, or passing a page through an automated accessibility checker, or quickly examining the code where suspected issues may be present, or running a page through a screen reader. These quick reviews often turn up a number of potential barriers that help get a discussion started on next steps toward making web content accessible.\r\n

Reporting Results from the Review<\/h2>\r\nThe following is an example of the types of issues that might be documented in an informal review. Characteristics of an informal review could include (in this example):\r\n
    \r\n \t
  1. Type of site:<\/strong> a registration system with integrated eCommerce<\/li>\r\n \t
  2. Timing of review:<\/strong> prior to going live<\/li>\r\n \t
  3. Duration of review:<\/strong> about 30 minutes<\/li>\r\n \t
  4. Audience:<\/strong> the developer of the User Interface (UI) created over a third party eCommerce system<\/li>\r\n \t
  5. Style of Report: <\/strong>\r\n
      \r\n \t
    1. Provided by email to the developer and the developer\u2019s management team<\/li>\r\n \t
    2. Brief and succinct<\/li>\r\n \t
    3. Written in a way that the developer would understand, already being familiar with the UI, and already being familiar with the technical language being used<\/li>\r\n \t
    4. A few non-accessibility related issues identified as a courtesy<\/li>\r\n \t
    5. Not too detailed if the review is intended to elicit a formal review<\/li>\r\n<\/ol>\r\n<\/li>\r\n<\/ol>\r\n

      Sample Informal Review by Email<\/h2>\r\n
      \r\n\r\nHi John,\r\n\r\nHere\u2019s a quick summary of the potential issues found on your registration site. If you like, we can arrange a time to talk about these issues, and the possibility of conducting a formal review that will address these and other potential issues in more detail to ensure that as many people as possible are able to access your site and to register.\r\n\r\nI've identified some issues and offered suggestions for possible fixes where applicable:\r\n
        \r\n \t
      • Associate labels with form fields by matching the for attribute in the label with the id attribute in the input element.<\/li>\r\n \t
      • Add aria-required=\"true\"<\/code> to the required input fields.<\/li>\r\n \t
      • Use aria-describedby=\"[id]\"<\/code> to associate the description in the hidden spans with the respective input field.<\/li>\r\n \t
      • The Yes\/No inputs look like checkboxes, but function like radio buttons. Maybe not an issue, but inconsistent with what most people might expect.<\/li>\r\n \t
      • For the footnote numbers next to Price and Group, aria-describedby could be used to associate the footnote with the number, or the numbers could be linked to an anchor next to the associated footnote.<\/li>\r\n \t
      • Because there are two levels of table header cells in the tickets table, they should use headers\/id to associate both levels of header, though in this case this is a trivial issue given the small size of the table.<\/li>\r\n \t
      • The checkbox looking button beside the credit cards accepted line is a bit confusing. It shows a hand cursor which suggests it should be clickable, but it\u2019s not.<\/li>\r\n \t
      • When an error message is displayed, include role=\"alert\"<\/code> in the div containing the message.<\/li>\r\n \t
      • When an error occurs, send focus to the first field that has an error.<\/li>\r\n \t
      • It was possible to submit the form for payment without the ticket holder email being valid.<\/li>\r\n \t
      • Clicking \u201creturn to form\u201d in the credit card popup hangs, apparently trying to access Google Analytics.<\/li>\r\n \t
      • In the credit card popup, focus should be trapped in the dialog in a loop until either Pay Now, Back to Form, or the Escape key is pressed.<\/li>\r\n \t
      • In the credit card popup, the initial checkbox and other form fields should be associated with the respective labels using the Label element (with matching for\/id).<\/li>\r\n \t
      • For the error message that appears in the credit card popup, add role=\"alert\"<\/code> to the span containing the message.<\/li>\r\n \t
      • The close X should have title text added such as title=\"close credit card details\"<\/code>.<\/li>\r\n \t
      • After submitting the credit card form, the screen hangs, again trying to access Google analytics.<\/li>\r\n \t
      • Unable to see the output after making a credit card submission, to determine if there are any issues at the final step.<\/li>\r\n \t
      • Unable to see how the tickets are issued, perhaps via email. Not sure if there are any issues there.<\/li>\r\n<\/ul>\r\n<\/div>\r\n ","rendered":"

        An informal review is a quick scan of a website to identify obvious accessibility issues. While these reviews do not represent exhaustive audits, they are useful for a variety of purposes.<\/p>\n

        Purpose of Review<\/h2>\n

        An informal review is often attached to a quote for a formal accessibility audit, providing some introductory information to a client to give them a better idea of the types of issues on their website before they commit to the formal review. An informal review can be helpful in justifying a formal review.<\/p>\n

        Process of Review<\/h2>\n

        Informal reviews often occur as part of a conversation, perhaps with a member of an organization who is responsible for managing an organization\u2019s image, or with a developer who is planning or reviewing design activities. These reviews will often involve a couple of quick tests, like the Tab Key Navigation test, or passing a page through an automated accessibility checker, or quickly examining the code where suspected issues may be present, or running a page through a screen reader. These quick reviews often turn up a number of potential barriers that help get a discussion started on next steps toward making web content accessible.<\/p>\n

        Reporting Results from the Review<\/h2>\n

        The following is an example of the types of issues that might be documented in an informal review. Characteristics of an informal review could include (in this example):<\/p>\n

          \n
        1. Type of site:<\/strong> a registration system with integrated eCommerce<\/li>\n
        2. Timing of review:<\/strong> prior to going live<\/li>\n
        3. Duration of review:<\/strong> about 30 minutes<\/li>\n
        4. Audience:<\/strong> the developer of the User Interface (UI) created over a third party eCommerce system<\/li>\n
        5. Style of Report: <\/strong>\n
            \n
          1. Provided by email to the developer and the developer\u2019s management team<\/li>\n
          2. Brief and succinct<\/li>\n
          3. Written in a way that the developer would understand, already being familiar with the UI, and already being familiar with the technical language being used<\/li>\n
          4. A few non-accessibility related issues identified as a courtesy<\/li>\n
          5. Not too detailed if the review is intended to elicit a formal review<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

            Sample Informal Review by Email<\/h2>\n
            \n

            Hi John,<\/p>\n

            Here\u2019s a quick summary of the potential issues found on your registration site. If you like, we can arrange a time to talk about these issues, and the possibility of conducting a formal review that will address these and other potential issues in more detail to ensure that as many people as possible are able to access your site and to register.<\/p>\n

            I’ve identified some issues and offered suggestions for possible fixes where applicable:<\/p>\n

              \n
            • Associate labels with form fields by matching the for attribute in the label with the id attribute in the input element.<\/li>\n
            • Add aria-required=\"true\"<\/code> to the required input fields.<\/li>\n
            • Use aria-describedby=\"[id]\"<\/code> to associate the description in the hidden spans with the respective input field.<\/li>\n
            • The Yes\/No inputs look like checkboxes, but function like radio buttons. Maybe not an issue, but inconsistent with what most people might expect.<\/li>\n
            • For the footnote numbers next to Price and Group, aria-describedby could be used to associate the footnote with the number, or the numbers could be linked to an anchor next to the associated footnote.<\/li>\n
            • Because there are two levels of table header cells in the tickets table, they should use headers\/id to associate both levels of header, though in this case this is a trivial issue given the small size of the table.<\/li>\n
            • The checkbox looking button beside the credit cards accepted line is a bit confusing. It shows a hand cursor which suggests it should be clickable, but it\u2019s not.<\/li>\n
            • When an error message is displayed, include role=\"alert\"<\/code> in the div containing the message.<\/li>\n
            • When an error occurs, send focus to the first field that has an error.<\/li>\n
            • It was possible to submit the form for payment without the ticket holder email being valid.<\/li>\n
            • Clicking \u201creturn to form\u201d in the credit card popup hangs, apparently trying to access Google Analytics.<\/li>\n
            • In the credit card popup, focus should be trapped in the dialog in a loop until either Pay Now, Back to Form, or the Escape key is pressed.<\/li>\n
            • In the credit card popup, the initial checkbox and other form fields should be associated with the respective labels using the Label element (with matching for\/id).<\/li>\n
            • For the error message that appears in the credit card popup, add role=\"alert\"<\/code> to the span containing the message.<\/li>\n
            • The close X should have title text added such as title=\"close credit card details\"<\/code>.<\/li>\n
            • After submitting the credit card form, the screen hangs, again trying to access Google analytics.<\/li>\n
            • Unable to see the output after making a credit card submission, to determine if there are any issues at the final step.<\/li>\n
            • Unable to see how the tickets are issued, perhaps via email. Not sure if there are any issues there.<\/li>\n<\/ul>\n<\/div>\n

               <\/p>\n","protected":false},"author":56,"menu_order":4,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[],"contributor":[],"license":[],"class_list":["post-1434","chapter","type-chapter","status-publish","hentry"],"part":1423,"_links":{"self":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/pressbooks\/v2\/chapters\/1434","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/wp\/v2\/users\/56"}],"version-history":[{"count":8,"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/pressbooks\/v2\/chapters\/1434\/revisions"}],"predecessor-version":[{"id":2283,"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/pressbooks\/v2\/chapters\/1434\/revisions\/2283"}],"part":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/pressbooks\/v2\/parts\/1423"}],"metadata":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/pressbooks\/v2\/chapters\/1434\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/wp\/v2\/media?parent=1434"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/pressbooks\/v2\/chapter-type?post=1434"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/wp\/v2\/contributor?post=1434"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.library.torontomu.ca\/pwaa\/wp-json\/wp\/v2\/license?post=1434"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}