> EOWG Home Page > Implementation Plan

Change Log: Implementation Plan for Web Accessibility

This page records change requests and changes made to the draft WAI Resource Suite Implementation Plan for Web Accessibility. Please send additions or corrections to w3c-wai-eo@w3.org.

Last updated $Date: 2004/10/28 21:00:54 $ by $Author: shawn $

Evaluation Resource Suite Changes Moved

http://www.w3.org/WAI/EO/changelogs/cl-eval.html

Change log from July 12, 2002

• Developing Organizational Policies on Web Accessibility
  • 
    
• Evaluating Web Sites for Accessibility
  • Move the "Note" to the end of the introduction section
  • Under 3.4 and 4.2.2: Add a caution about false positives: "Using at least two evaluation tools helps catch potential misidentification of accessibility problems that might result from using a single evaluation tool."
  • For 3.1.1. 3.1.2, 3.1.3: drop disclosure as proposed, break up 1.2 & 1.3 sentences, also "for purposes of"; also, break out the Note. and remove "to be disclosed 
  • Under 3.2.1. htmlhelp.com/tools/validator. *JB talk to our systems team about site-wide validation. "The following are examples of validation tools..." *JB talk to systems team about other tools. 
  • LATER: deal with the issue of validation not being a pri-1 item on the next round of eval doc work, where we break out testing techniques by checkpoint & priority level.
    

Change log from July 10, 2002

• Selecting and Using Authoring Tools
  • [software-002] Under "Evaluating software currently in use" take out the two introductory sentences that were just added to this section, (since they create potential misunderstandings about where responsibility for evaluating current tools lies); e.g. take out "Solicit feedback from Webmasters and content developers..." and make new bullet within that section but at end of list (e.g. after bulleted item "for authoring tools which do not support...") which states: "Seek feedback from Webmasters and content developers..." and also:
  • [software-003] Under "Selecting new or replacement software" after the last bulleted item, insert "Also ask Webmasters and content developers for suggestions of other tools and utilities that might be more effective" which was removed from the new introductory sentences.
  • [software-004] After the new last bullet in the section called "Evaluating software currently in use" add "and if possible ask them to show you how the tools supports production of accessible content."
    
  • [software-005] at new #12 on alt text registry, clean up typos & finish phrase "...for doing so."
  • [software-006] at new #12 make the two neighboring checkpoint refs run-in. 
  • [software-007] each time where "5.1-5.4" (#8 & #11) appear, make the links go to 5.1 for starters. 
  • [software-008] clarify WRT SH's question on "skip this question" that we do not want to ask the site _users'_ perspectives on authoring tools, just the site _developers'_ perspectives.
  • [software-009] under "Selecting new or replacement software:" add a question stating: "If localization (translation) of authoring software or accessibility plug-ins is relevant to this organization, are accessibility features available in localized versions?"
  • [software-010] clarification on reply on 3-column question: nice idea for later, but let's this get this out now without reformatting.
    

Change log from June 28, 2002

• Evaluating Web Sites for Accessibility [CL June 26 draft]
  • [eval-012] 4.X first level: Evaluate all templates. second level, two points. first point: Evaluate static templates using WCAG 1.0 Conformance. second point. Add a minimal amount of plain text content to template and re-evaluate WCAG conformance. Replace existing text in templates section completely.
  • [eval-013] 4.X [From "content" section] move "if all dynamic content" down to 2nd bullet under templates & content combined. 
  • [eval-014] 4.X [Under "content" section] add a bullet asking about the content itself: "evaluate the content to ensure that it  includes valid markup, with necessary accessibility information where appropriate"
  • [eval-015] 4.X [Under "templates and content combined"] first point: "for pages that are generated...."; second point: "if all dynamic content cannot be evaluated..."; 
  • [eval-016] 4.x [Under "templates and content combined"] third point: "do the generated pages retain the accessibility features evaluated under templates and content when combined" then as a nested bullet, "does the generated tab order from the template..."
  • [eval-017] 4.x [Under "templates and content combined"] edit "fed back into evaluation tool" say instead "evaluated using WCAG conformance testing."
  • [eval-018] 2.2.5 and 3.2.5 [testing of color contrast] EOWG acknowledges that this is imprecise, recommends minimal switch. "observe whether the color contrast is adequate by changing the display color to gray scale (or print out page in gray scale or black and white)"
    
• Selecting and Using Software for Accessibility [SH June 27 draft]
  • [software-002] "if your authoring tool does not provide a means for storing alt text, develop a system for doing so"
    

Change log from June 26, 2002

• Evaluating Web Sites for Accessibility (CL June 26 draft)
  • [eval-007] [DONE] fix markup on ordered lists in this version
  • [eval-008] [3.x] [CONFIRMED] "usability testing of accessibility features" -- this is the winner 
  • [eval-009] [4.x] [CONFIRMED] "evaluate all distinct templates" change to "evaluate all templates"
  • [eval-010] [4.x] [SEE #012 ABOVE] "if templates are generated..." need to refer to ATAG 1.0, not Selecting Authoring Tools. Point to specific sections of the guidelines.
  • [eval-011] [4.x] [CONFIRMED] title of section: "evaluation of database driven dynamically generated web pages" change to "evaluation of dynmically generated Web pages"
    

Change log from June 14, 2002

• Evaluating Web Sites for Accessibility (CL's June 13 draft)
  • [eval-001] [3.1.1] Change order & content of steps: (1)  ID target conformance level; (2) identify page selection (for manual and user testing selection); (3) identify entire scope of site (and explain why). 
  • [eval-002] [3.1.1] Provide fall-back option of using expanded page selection if entire site is not feasible
  • [eval-003] [3.1.1] Clarify disclosure expectation: internal during eval, external post eval _if_ the conformance claim itself is external.
  • [eval-004] [2.2.1 and 3.?.?] Substitute "capture content" for "freeze" from previous change log notes refering dynamically generated content. Minimal detail; link to section lower in document.
  • [eval-005] [3.3.1] Clarify "Examine page selection using relevant level checkpoints" change to "Examine page selection using checkpoints that are applicable to your site"
  • [eval-006] [3.2] "Use a voice browser..." Clarify the note: separate text browser from screen reader techniques; and move the notes into 3.1.1
    
• Evaluation and Repair Tools
  • [tools-001] [whole list] Add more information to evaluation tools lists about large-volume evaluators; 
  • [tools-002] [whole list] Note when the comments against each tool on the list were made;
• Selecting and Using Software for Web Accessibility 
  • [software-001]
    

Change log from June 7, 2002

• Developing Organizational Policies on Web Accessibility
  • [DONE] slightly edited introductory phrases to remove references to appendix, and increase readability.
  • [DONE] added dated URI to comprehensive policy.
  • [DONE] removed placeholder link to benefits of standards harmonization document until it is available to link to.
• Evaluating Web Sites for Accessibility
  
  • FOR LATER: either specify which checkpoints the evaluation approaches relate to, OR link to more precise evaluation techniques
  • Clarify the introduction to indicate that this is not check-point by checkpoint conformance, and that other guidance will be available. 
  • Also clean up the introduction to the conformance section itself.
• from previous discussion, check where:
  
  • does the proc pol requ the purchase of auth tools that support production of accessible docs
• selecting software
  • add in wcag links and atag links under workarounds
    

Change requests from April 12, 2002

• eval doc
  • add note explaining status of draft version
  • add comments addressing dynamically generated pages
    • add: on web sites with database driven dynamically generated web content, generate broadly representative samples, freeze, and test the output;
    • evaluate the capability of the content management system to store and generate accessibility information; cf ATAG evaluation approaches, and "selecting software" document.
    • [20020412] if evaluating templates, then beware this pitfall: "add: on templates, evaluate all, or a broadly representative sample, and also evaluate the capability of the templates to store accessibility information." caution: it is not adequate to simply evaluate the accessibility of web site templates that are in use, many of the accessibility features are embedded in the content as well.
    • [20020412] for pages that are generated as a result of a query to a database, the source generated as the page is rendered should be fed back into the evaluation tool -- [requires operator intervention]

Change requests from comments to EOWG editors' list.

• eval doc, dated 20021011
  • original request for review [20011002]
  • tabbing problem in document header [20011012] reply; still a problem; later development; check fixed?
    • [20020405] reply that we think it is fixed in the new version
  • lack of clarity of "appropriate sequence" and "logical order" [20011012]
    • DONE/CL/20020523 [20020405] instead of appropriate sequence, change to "turn off images, and check whether appropriate alternative text is available. DONE/CL/20020523 remove sequence"
    • DONE/CL/20020523 [20020405] instead of logical order, change to "in a meaningful order if read serially"
  • clarify 3.1.1 vs 3.1.2, "selection" vs. "expanded selection" [20011022]
    • also page selection section of comp. eval very confusing [20011030]
    • and concern about how (non-)spidering of tools interacts with page selection [20011030]
    • DONE/JB/20020523 [20020405] .1 "identify" change to "determine"
    • DONE/JB/20020523 [20020405] in intro to section 3, replace all "comprehensive" with "conformance"
    • DONE/JB/20020523 [20020405] new 3.1 should become "identifying target conformance level to eval to"
    • [20020405] add intro language explaining why need two sets; if the size of your site precludes evaluating all pages ("if you have to" mode) choose a page selection, but must disclose larger set: start w/ assumption that this is the entire site; IF site is too large, can declare a smaller set but must disclose (at end of review); IF site format is very redundant, then...[20020412] no, emphasize that the default for the larger set is the whole site, unless: uncommonly large, use of common template throughout the site..."go with saying, do all of the pages in your site, except in circumstances where it is unrealistic...."
    • [20020405] new 3.2 choose a small set
    • [20020405] new 3.3. choose a large set, preferrably the entire site, otherwise restricted set which will need to be disclosed at end of the review [and then remind them again at the end]
  • 3.2.2 more diversity in tool examples [20011022]
    • DONE/CL/20020523 [20020410] remove the "as above" in comprehensive, and repeat it explicitly in compr review (re-cite the external ref list);
    • [20020410] add a note that translations exist in other langs and/or original tools (we also need to incorporate those into the ref list;
    • DONE/CL/20020523 [20020410] problems indicated by the tools. the following are sample eval tools, and a more extensive list is available at...
    • [20020410] action jb: request advice from w3c comm team on how to apply general w3c practices on naming products (or not) within the type of documents we are developing in EOWG. Need a comprimise, link to long list that includes free, and to OK sample starters. Add a disclaimer at bottom of document in which any products are mentioned: not an endorsement, if no vs id is provided, no specific vs id is to be assumed.
  • 3.3.3 clarify Jaws is the only tool provided by the Danish government [20011022]
    • DONE/CL/20020523 [20020410] change "JAWS is the only screen reader translated into Danish, and therefore in Denmark, a trained evaluator should evaluate the Web site using JAWS" to "JAWS is the screen reader provided by the Danish government, and therefore a trained..."
  • include techniques for testing for wcag 2.0 checkpoint 3.4 [20011022]
    • [20020410] reply as follows: this doc specifically re wcag 1.0 eval conf therefore inappropriate to add techs for 3.4 in 2.0, thx, tho, and will keep for future ref.
  • 3.2 & 3.3, suggest testing in voice browser over linear view [20011022]
    • [20020410] ordering is suggested/informative, and also for ease of ref but not absolute. optimal order of steps will vary.
  • 2.2.3 clarify purpose of changing the font size [20011030]
    • DONE/CL/20020523 [20020410] (1) clarify _will_ the font size change on the screen accordingly; and is the page still usable. [revisiting on 20020524] Change the display color to gray scale (or print out page in gray scale or black and white) and observe whether the color contrast is adequate.  
  • 2.2.4 clarify purpose of changing screen resolution [20011030]
    • DONE/CL/20020523 [20020412] test with different screen resolution,and/or by resizing appication window to less than maximum, to verify that horizontal scrolling is not required (caution: test with different browsers, or examine code for absolute sizing, to ensure that it is a content problem not a browser problem)
  • 2.2.5 questioning what printing page accomplishes [20011030]
    • [20020412] it is useful for some people, so we will leave this in, however it's not required and you don't have to use it.
  • 2.2.6 clarify without the mouse [20011030]
    • DONE/CL/20020523 [20020412] agreed, change to without the mouse [REVISITING ON 20020524] Leave text as is, following much discussion of whether to remove the final phrase about links indicating what they lead to; whether to keep but separate into two different steps; whether to keep both steps in this section; whether to remove the word all; whether to separate the links point and the forms point; whether to change the intro paragraph for this section. Conclusion: enough reasons for keeping it all as it is; if it's really unclear, we can count on people to let us know.
  • tell reviewers what to look for at each step [20011030]
    • [20020412] agreed, and revisit each point to check, after updating document
  • upgrade background needed for preliminary review [20011030]
    • [20020412] rather than upgrade background needed, we prefer to have people get engaged in review, not treating results of prelim review as definitive, but at least getting started... and encourage people to go to a conf review for more detail. point her to intro.
  • explain more about what to look for in code when reviewing data tables in lynx [20011030]
    • [20020426] add a Note in #2, "don't use lynx on data tables." (provide a link to somewhere where it's defined)
  • comprehensive evaluation intro, involvement of users too broad [20011030]
    • [20020426] clarify that full comprehensive evaluation is not necessarily what we recommend in the ongoing monitoring section; but that ongoing feedback opportunity; after bigger changes; customizing certain automated and semi-automated tests based on the problems identified in comprehensive evaluation. so, it does not necessarily include repeated user testing. specifically, after major changes [design update or template, or major reorganization of materials], or after a longer period of time such as a half year or year, you've got to run another comprehensive test again.
    • [20020426] Usability testing: change to user testing of accessibility features. ... are useful, and ask users to find answers... ask users to focus on accessibility features, ... ask users to find answers to common questions and observe how they use certain aspects of accessibility features. "You can ask testers to try to find answers to the most common questions and note areas where it is difficult or impossible to use the Web site."
  • confusion about page types [20011030]
    • [20020426] remove reference to entry pages... top level pages on which people are more likely to enter your site
  • clarify differences between #2 and #4 on legacy sites [20011030]
    • [20020426] clarify that step #2 is internal and step #4 is external. break apart #1.
  • provide more context [20011102]
    • [20020503] we try not to make our documents redundant with each other, but we will provide more pointers. need to add in a sentence to hang it on.
  • provide a printable checklist [20011102]
    • [20020503] printable checklist is a good way of looking at an overview, could be useful. useful for many bureacracies. set it up w/ visual aide like diagram. strip what's in eval doc steps and provide summary/overview only; then put the detail in linear checklists. contract the list in the doc itself, put the rest into checklists. agreement that there is need for checklist, but too many questions to do them quickly... will work on later. questions would need to address: either/or and and/or options; multiple pages; outcome of evaluation not process of evaluation. we will learn a lot from it, and it may force a reevaluation of some of the items.
  • provide more detail on how to do some of the steps [20011102]
    • [20020503] wrt doing steps in specific browsers, we don't want to explain how to do things on a product-by-product basis. [add a line or a sentence saying that you can change these things using your browser preferences, or your computer preferences, depending on the case... some things relate to operating systems, some are browser specific. group them: os settings, browser settings. btw, some of these are...] If additional questions come in on how to do steps, we will address them.
  • is it too comprehensive to be commercially viable [20020218]
    • [20020503] If you find audio content on a site, turn off the review. At this point we feel that all these steps are nec for eval. WRT ROI, we don't yet have clear data; after release of updated version, as one of our revw qu's we will ask whether any steps are unnec or have particular low ROI. Also working on sep doc of business benefits of accessibility. Do people see anyway to reduce the steps without comprimising the evaluation... we're also looking for more automated ways.

    [hb - encourage use of logo]

Change requests from 24 March 2002

• eval doc
  • publish as is for now (w/ regard to format) as part of impl suite
  • add a small note at conf eval section stating that this part may be extracted into a note, look for that
  • leave all section but conf evaluation intact in place in impl suite
  • soonish? move out the conf eval section into a w3c note w/ strict version control
  • maintain cross linking to show what's needed in other section
  • careful about pulling apart the document too much and removing context -- re-examine the issues:
  • CAREFUL, NOT A DEFINITIVE DISCUSSION!

Change requests from 13 March 2002

• Comments on http://www.w3.org/WAI/EO/Drafts/impl/
  • navigation now!
    • plus-minus icon for expansion
    • page contents: at the beginning of page nav
    • try replacing training suite + expander w/ ... again
  • navigation later!
    • explore better ways to indicate that the training suite has got more content when you get there
• Comments on process for issue tracking
  • agreed to use existing doc change logs to track, by linking, to comments that have come in, and provide info on how resolved. JB: complete inventory and linking to those and proposals for how to address

Change requests from 28 February 2002

• Comments on whole package
  • navigation now!
    • CONFIRMED add "this page" before page links
    • CONFIRMED take out the training suite so it is a stand-alone as a suite, and make sure that there are lots of ways to get back
    • CONFIRMED putting back the toggle choice option
  • navigation later!
    • CONFIRMED provide some means of knowing [such as breadcrumbs, and/or back to top] where one is when one jumps down to a header on same page
    • CONFIRMED do usability studies
    • CONFIRMED develop style guide and consistent navigation across W3C site
    • CONFIRMED continue working on other solutions to the jumping problem w/ the XSLT transformations, more indicators of where you've been
  • evaluation
    • cut down introduction a bit without removing essence
    • clarify the reason for provision about familiarity of the site
    • provide more guidance (later) on usability within the evaluation process

Change requests from 13 February 2002

• Comments on selecting software 4
  • Confirmation/acceptance of change requests from 11 February?
    • for "what are your current users saying" -- "how do you feel this tool facilitates creating accessible sites, and do you suggestions for other tools that would do the job better" also "are there other utilities that would help" -- don't add a lot of words but make it clearer that webmaster opinion is solicited.
    • list utilities for storing & reusing alt text if available -- SVG graphic format...
  • Clarification of what EOWG wants from AUWG, if possible:
    • ERT WG's tools lists (not AUWG, ERT WG)
    • have some send-out (friendly) form (EOWG, not AUWG)
    • AUWG should date their reviews, version, and platform -- confirm that is happening. reflect it on the list as well. (HBj send links)
  • Responses to PJ's comments:
    • EOWG maintains on need for EOWG heads up on status of AUWG reviews
    • Chop down intro by 50% if possible but keep the list of guidelines
    • Take the intro draft note out after all changes from 11 Feb & 13 are done (check new example first)
    • Clarify 3 columns
    • Explain about page within a suite -- wait until -- defer until the implementation suite is ready...
    • EOWG not in favor of adding icons all over the page
    • Don't make it look more like a checklist -- rename it to considerations for... rather than checklists...

Change requests from 11 February 2002

• Comments on selecting software 4
  • incorporate user feedback "what are your current users saying" -- what users are we excluding from// what are users saying about the accessibility of the product// what users of the site are saying... no... skip that question...
  • mention A-Prompt as work-arounds for 4.1 and 4.2
  • storage & re-use of equivalent alternatives... create one's own system
  • cover localization issues in the product reviews, and local languages... //is localization an issue? //is it supported//
  • can you use another language plug-in with a local language
  • [AUWG -- suggestion from EOWG to add in links to compatible plug-ins, in reviews of mainstream tools]

Change requests from 25 January 2002

• Comments on selecting software 4
  • Add an example about how forms and complex tables having to be marked up by hand: "If an authoring tool does not provide support for accessible markup of complex data tables and forms, mark them up by hand."
  • DONE For authoring systems primarily designed to produce print media (Acrobat, PageMaker, Quark Express), rich media (Director, Flash, ToolBook), word processing (Word, Word Perfect), presentations (PowerPoint, Freelance, Visio), choose formats carefully & clean up well.
  • DONE Change voice in vendor questions, no 2nd person "you"
  • DONE Can a suite of tools be established to provide the accessibility that the authoring tool lacked?
  • DONE Change asking to questioning
  • DONE "develop an in-house process or checklist for checking and publishing documents with these tools." change to for correcting accessibility problems.
  • DONE fix brackets on tables example
  • DONE add WAVE as a solution for #8

Change requests from 18 January 2002

• Comments on selecting software 4
  • NOT [removed lower section] add: (see lower section on atag)
  • NOT [creates wrong implication] change: subtitle of guidelines for authoring tool developers
  • NOT [is this necessary? would involve major re-working of the document, trying to finish] try working with key resource model
  • NOT [re-examined; would be redundant] add: reviews authoring tools _for accessibility_
  • MOSTLY DONE [take a look] #4 then also post accessible html files; also "and" not "to"; and/or go back to the original source material from which the pdf file was generated (put this somewhere near the beginning: use original source and check accuracy) ..... #4 make the example more generic but include such as [PDF, Flash, PowerPoint] and then make the solutions more generic and have triple levels: go back to orig source OR run through converter and check OR recreate .....#4 for authoring systems such as for print media (...), rich media (...), presentation formats (...), word processors (...)
  • LATER compile more converter/transformation resources
  • do experiment #3 on suite nav: horizontal
  • LATER compile: a list of plug-ins
  • DONE take off parens on diff types of tools
  • DONE add question regarding whether some tools destroy the work of others
  • DONE conversion tools that save as html, such as word processors or presentation software
  • DONE rephrase: Are there plug-ins, retrofitting tools, or other utilities that could be used together with existing software to better support the production of accessible Web sites?... For authoring tools that do not support the creation of accessible content, are there plug-ins or other utilities that can be used with that/those products?
  • DONE also add this question to what to ask vendors
  • DONE add: if you do business with a government that requires Web accessibility, what changes have you made to your product?
  • DONE re-flip the document: 1 checklist, 2 work-arounds, 3 product reviews, 4 atag
  • DONE further eliminate the redundancy between intro & guidelines section
  • DONE take out the links on atag guidelines but put it up in the intro in the list
  • DONE take out the remaining section on atag
  • DONE as of the last revision of this document, the reviews available .... were not up to date... and therefore may not represent the latest progress in atag-conformance
  • DONE become familiar with the general concepts (at the guideline level, not necessarily the individual checkpoints) in WCAG 1.0 and ATAG 1.0;
  • DONE clean up w/
  • DONE #2 if auth tool does not create valid according to a published dtd
  • DONE #3 add omitted atag reference
  • DONE change alt tag for arrow to "you are here"

Change requests from 16 January 2002

• Comments on selecting software 4
  • [NOTE: edited in place during the meeting. Notes coming.]

Change requests from 11 January 2002

• Comments on navigation in selecting software3 and implementation plan-rd and implementation plan
  • change title of suite to implementation planning resource suite for web accessibility OR add a new top page on suite
  • try suite nav on implementation page as its own overview AND try w/ new mini-overview page to introduce the set
  • [HOW not in span?] use display none in place of skip nav but NOT as part of span or div;
  • [NEEDED? if using "suite"?] use display none to label each nav bar invisibly except screen readers
  • LATER come up with a usability testing on empty templates
  • NOT [because conflicts with hover color] keep the background color on pagenav
  • NOT try revealing more words w/ hover or on-focus for training
  • NOT [float worked] try wainav2 with two rows & a table
  • DONE keep the suite nav vertical
  • DONE [as implementation suite] change implementation plan to implement planning suite in suite nav
  • DONE [as training suite] substitute plus sign for "..." after training
  • DONE try putting the nav bar on the right in a float (separate experiment)
  • DONE get the hyphens out of the hover links

Change requests from 4 January 2002

• Comments on new draft of implementation plan
  • move version-toggle down to under page contents -- but re-checking once page is collapsed to make sure it flows well
  • differentiate nav bars more w/ layout & formating -- sh & jb talk
  • clean up section on existing organizational policy
  • move some of selecting sw content out to other more specific resource
  • say something more explicit about work-arounds w/ current sw
  • take out "expanded" & put at end
  • re-xslt
• Comments on new draft of selecting authoring tools
  • add checkboxes
  • HOW? make the other questions more grounded
  • DONE add questions about your existing software
  • DONE add questions about the procurement process
  • DONE add questions for vendors
  • DONE some specific considerations for workarounds with existing sw
    • familiarize yourself w/ atag requirements
    • identify key limitations of sw wrt to your development needs
    • look for plug-ins or clean-up utilities that can be used in combination w/ a given software to correct output (think about re-org)
    • develop a process for using these tools in combination
  • DONE flip the 2nd & 3rd intro paragraph, consider shrinking 2nd, drop it into key resource format w/ explanation
  • DONE fix the change log link
  • DONE strip top level of checklist bullets
  • DONE change subtitle to checklists
  • DONE add mini list of direct vendor questions
  • DONE split list, questions for vendors, questions for organization itself (flip)
  • DONE! address issue of work-arounds

Change requests from 19 December 2001

• Comments on Selecting Software for Developing Accessible Web Sites
  • make it more blatant that there is not a straightforward solution: start by saying that no single tool exists at this point
  • make it clearer that this is authoring software not retrofiting and evaluating software: Selecting Authoring Tools for Accessible Web Sites
  • make it clearer that it is also making sure that the UI is xsbl to pwd
  • add all custom authoring system developers
  • ...and to understand the limitations to work around in given products
  • software guidelines section... how useful is it... title is unclear... change to "ATAG: Guidelines for Authoring Tools"
  • add a sentence... industry is moving towards...
  • write checklist sample questions... targeted
  • flip doc & get the questions up front, but acknowledge that we're not giving them what came here for
  • new section name: checklist for authoring tool selection
  • grab first 2 sents of vendor query & throw them in introduction or toss out
  • leave 3rd sent as lead-in, regularizing vocab, chop out all extra words
  • flesh them out and make them more pointed.

Change requests from 14 November 2001

• Comments on implementation plan new format
  • do the edits we have & throw out to WAI IG for comment, send w/ a request for help
  • add in remaining Web design & government comments

Change requests from 2 November 2001

• Comments on implementation plan new format
  • put background into the expanded section; will help the shift of viewport focus
  • move up the "expand all" instructions to under the mini-nav bar & drop expand all from mini-nav
  • talk to Dom about xmlns shape rect anchor holder -- suppressed in Web Formatter (an add-on in Internet Explorer to help screen reader)
  • add punctuation!! makes screen readers work better. use punctuation at end of list items
  • add curriculum for training under training section
  • education: include representation from each school, district, jurisdiction, commission, etc.
  • large organization, multiple items: group as 3rd level bullet
  • REVIEW TEAM: LC (school + other perspectives), JMA (small organizations), DS (large organizations), CV (corp, research, web design)

Change requests from 26 October 2001

• Comments on updated drafts implementation plan and expanded implementation plan
  • NOT YET add detail to policy expansion pointing to simple high level and to comprehensive statements
  • DONE try implementation of server-side solution for expanding detail, before trying client side solution
  • DONE: SECTION BY SECTION. SERVER BURDEN otherwise. go for bullet-by-bullet expansion if the time response is good; if time response is bad, expand by section
  • DONE jb talk with some of our systems team guys
  • DONE "...and optimal order of the steps below will vary as well"
  • DONE AGREED to expand detail uniformly all environments
  • DONE "establish coordination team with communication plan"
  • DONE strip off numbers from everything
  • DONE "develop, promote, and support organizational policy"
  • DONE merge 6 & 7, merge feedback points
  • DONE add in a loopback mention to champion and to policy as needed
  • DONE turn over, replace with something... "as staff and responsibilities change"
  • DONE "as many of" w/ authoring tool
  • DONE select evaluation & repair tools
  • DONE add detail to finding out about external requirements -- for govt & commericial sites, this should come first...
  • DONE THEN UNDONE [moved back down to policy section] move up policy points within initial assessment category
  • DONE on detail page, un-scatter the environmental notes, regularize the way they're presented, and alphabetize
  • DONE keep generalized detail comments, but position at top of each detail section

Additional changes done 25 October 2001

• Changes made on updated implementation plan
  • DONE dropped suite nav (unnecessary?)
  • DONE edited down word count
  • DONE split page long/short
  • DONE added more detail
  • DONE merged some h2's

Change requests from 19 October 2001

• Comments on first merged version of implementation plan umbrella page
  • AGREED proceed with split resource suite (bcase and impl plan)
  • AGREED to try stripping top page and creating some kind of expandable detail
  • DONE removing the word "management" from intro
  • DONE replace "useful" with "critical" in intro
  • DONE replace "assign coordination" with "establish responsibilities"
  • DONE change "assess baseline" to "conduct initial assessment"
  • DONE THEN UNDONE add "establish priorities and needs" new H2
  • NOT under organizational policy, note that if one does not exist, then need to do
  • SOME ensure sufficient resources for initial and ongoing work

Copyright  ©  2000-2002 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.