Skip to content

Instantly share code, notes, and snippets.

@jrpool

jrpool/2018-01-02_work_plan.md

Last active February 12, 2018 19:12
Show Gist options
  • Save jrpool/7c4fa6f01a7a4b9b79e816956a6fbadf to your computer and use it in GitHub Desktop.
Save jrpool/7c4fa6f01a7a4b9b79e816956a6fbadf to your computer and use it in GitHub Desktop.
Download ZIP
7-week work plan
Raw
2018-01-02_work_plan.md

Work plan for final 7 weeks

Work plan for week of 2017-01-02

Work plan for week of 2017-01-08

Work plan for week of 2017-01-16

Work plan for week of 2017-01-22

Work plan for week of 2017-01-29

Work plan for week of 2017-02-05

Work plan for week of 2017-02-12

Work plan for final 7 weeks of Guild enrollment (2018-01-02 to 2018-02-16)

Goal: Further develop competence in “interface quality” (IQ) as a specialty in full-stack web development

By “interface quality”, I refer to software’s efficacy in interaction with humans and applications. The humans who interact with software are not only end-users, but also specifiers, developers, documenters, evangelists, demonstrators, developer-users, explainers, reviewers, and procurers.

Elements of interface quality to be included in this specialty

  • Documentation quality
  • Specification quality
  • Reusability
  • Extensibility
  • Maintainability
  • Stylistic consistency
  • Parsability
  • Intuitivity
  • Usability
  • Universality (responsiveness)
  • Accessibility (a11y)
  • Internationalization (i18n)

Work to be performed

  • Review whether some elements should be removed from the work plan
  • Study norms/standards/regulations/laws
  • Study tools
  • Retrofit own existing apps
  • Contribute to open-source tools
  • Engage with SIGs
  • Blog
  • Seek employment opportunities

Work plan for week of 2017-01-02 to 2017-01-05

Goal: Remediate my weakest IQ element

Motives

  • Be better able to plan work for remaining weeks.
  • Be better able to retrofit existing apps for all IQ elements in one pass.

Agenda

  • Identify a11y as my weakest skill among the focus aspects. Done. Notes:
  • Study U.S. federal law. Done.
    • Section 508 in 1998 amendments to Rehabilitation Act of 1973 (29 U.S.C. § 794 (d)), including text of the statute. Done. Notes:
      • Statute requires only U.S. federal agencies to provide IT equally to disabled users, unless unduly burdensome, and then to give them equal access by other means.
      • Requires rulemaking, monitoring, and reporting.
      • Grants disabled users a right of legal action for noncompliance.
      • Does not define “disability”, but the ADA defines a person with a disability as “a person who has a physical or mental impairment that substantially limits one or more major life activities, a person who has a history or record of such an impairment, or a person who is perceived by others as having such an impairment. The ADA does not specifically name all of the impairments that are covered.” This definition suggests potentially infinite costs for full compliance, except for the “undue burden” exception.
    • Architectural and Transportation Barriers Compliance Board, Information and Communication Technology (ICT) Standards and Guidelines, 2017-01-18 Final Rule, 36 CFR Parts 1193 and 1194. Done. Notes:
      • Rule enforces Sec. 508 of Rehab Act and 1 other statute.
      • My review limited to the 508 part.
      • Compliance required starting on 2018-01-18.
      • This revision is first since original 1998 standards.
      • Defines ICT (info & communications technology) to include “computers, information kiosks and transaction machines, telecommunications equipment, multifunction office machines, software, Web sites, and electronic documents.”
      • Rule is enforceable not directly, but by incorporation into U.S. agencies procurement requirements. (But if an agency itself creates a website, is that procurement? If not, exempt?)
      • 1998 product-based organization replaced by functionality-based one, reflecting growth of multifunctionality in products.
      • Standards “incorporate by reference the Web Content Accessibility Guidelines (WCAG) 2.0 …. … all covered Web and non-Web content and software – including, for example, Web sites, intranets, word processing documents, portable document format documents, and project management software – is required, with a few specific exceptions, to conform to WCAG 2.0’s Level A and Level AA Success Criteria and Conformance Requirements.”
      • Rule harmonized not only with WCAG 2.0, but also EN 301 549 (EU), “in the form of ensuring that the relevant accessibility specifications in such standard and the final rule can both be met simultaneously without conflict” (especially re adaptations for vision disabilities and re RTT).
      • Justification given for harmonization: It “creates a larger marketplace for accessibility solutions, thereby attracting more offerings and increasing the likelihood of commercial availability of accessible ICT options.”
      • Corrects misinterpretations of 1998 standards that counterproductively applied them to assistive technology, instead of only requiring interoperability with it.
      • Existing ICT exempt from being upgraded.
      • Impact analysis estimates costs and benefits of compliance, but excludes from benefits increased GDP and tax revenue from increased productivity of disabled non-federal-employees. Costs about 225% of benefits. But, per Executive Order 13563, it also recognizes unquantified benefits, including “greater social equality, human dignity, and fairness”, and estimates they exceed the quantified ones.
      • Applies most of WCAG 2.0 to non-web documents, too, including PDF docs, rather than applying PDF/UA-1 standard to PDFs (but recommends PDF/UA-1 as informative). But requires that “authoring tools capable of exporting PDF files must conform to PDF 1.7 (= ISO 32000-1) and be capable of exporting PDF files that conform to PDF/UA-1”.
      • Notes obsolescence of TTY and its replacement by varieties of RTT, but the immaturity of and lack of consensus on RTT, so does not mandate it for real-time-speech apps but notes usefulness of EN 301 549.
      • Requires that ICT have “features making its use by individuals with limited cognitive, language, and learning abilities simpler and easier.”
      • Notes that estimated 5% of non-institutionalized population has cognitive disabilities.
      • Conclusion: Defers to WCAG 2.0 and EN 301 549 for specific measures.
    • Federal Acquisition Regulations System, Federal Acquisition Regulation, Subpart 39.2. Done. Notes:
      • Does not resolve the vagueness of “undue burden”. Defines it as “a significant difficulty or expense”. If anything, it could negate the effect of the standards by exempting almost any compliance. But “significant difficulty or expense” is also the definition of “undue hardship” in the ADA, and it has been interpreted to be measurable in relation to “the cost of the accommodation, the overall financial resources of the employer, and the type of operation of the employer”, and “not merely to the costs that the employer is asked to assume, but also the benefits to others that will result”.
      • This regulation also says a burden determination must take account of the “resources available” to the agency.
  • Study other federal, state, and foreign accessibility law. Done. Notes:
    • 21st Century Communications and Video Accessibility Act of 2010 (CVAA). Done. Notes:
      • Marginally relevant to web development, but regulates browsers and video documents.
    • Proposed DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the approximation of the laws, regulations and administrative provisions of the Member States as regards the accessibility requirements for products and services. Done. Notes:
      • Specifies requirements for transportation- and banking-related websites.
      • Requirements include:
        • compatibility with assistive devices
        • inclusion of alternative formats
        • user adjustability of color, audio volume, font size, and foreground-background contrast
        • availability of sequential controls to subsitute for controls requiring highly granular motor control
    • LAW OF THE PEOPLE’S REPUBLIC OF CHINA ON THE PROTECTION OF PERSONS WITH DISABILITIES. Done. Notes:
      • Abstract and hortatory.
      • Applies to employment, education, mass media, building construction, and transportation.
      • Ignores computing, Internet, and email.
    • Article 47 of Loi n° 2005-102 du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées, as amended in 2016. Done. Notes:
      • Requires websites to be accessible or subject to an accessibility plan.
      • Requires home pages to inform users of the sites’ compliance or noncomplience with accessibility standards.
      • Applies (unnamed) international standards.
    • California law summary. Done. Notes:
      • California’s requirements were increased in December 2017, effective July 2018.
    • California [Government Code § 7405]. Done. Notes:
      • Requires “state governmental entities, in developing, procuring, maintaining, or using electronic or information technology,” to comply with U.S. law and regulations (508 of Rehab Act and 36 CFR 1194).
      • U.S. law does not apply to the states, so this is not redundant.
      • Requires private entities that contract to provide ICT to the state to accept and resolve accessibility complaints.
    • California Government Code § 11546.7. Done. Notes:
      • Requires each state agency to post on its home page a self-certification of compliance with Government Code §§ 7405 and 11135 and with WCAG 2 level AA.
      • Requires a standard procedure for testing for compliance.
      • § 11135 requires nondiscrimination by state and state-supported entities on many bases, including physical and mental disabilities.
    • Summary of U.S. state law. About 12 states have laws on accessibility of software, either in general or as procured by state governments.
    • Convention on the Rights of Persons with Disabilities. Done. Notes:
      • Requires state parties to “take appropriate measures to ensure to persons with disabilities access, on an equal basis with others, to … information and communications, including information and communications technologies and systems …”, and to “promote access for persons with disabilities to new information and communications technologies and systems, including the Internet”.
      • Requires state parties to “take all appropriate measures to ensure that persons with disabilities can exercise the right to freedom of expression and opinion, including the freedom to seek, receive and impart information and ideas on an equal basis with others and through all forms of communication of their choice, … including by … Urging private entities that provide services to the general public, including through the Internet, to provide information and services in accessible and usable formats for persons with disabilities”.
      • Requires state parties to encourage R&D, training, and support for universal design and accessible design for compatibility with low-cost assistive technologies.
      • No enforcement. Optional protocol provides opportunity for complaints to a committee and its investigation of complaints, but investigations and hearings are “confidential” and violations, if found, are not subject to any sanctions.
  • Study industry standards. Done. Notes:
    • Accessibility Guidelines Working Group, Web Content Accessibility Guidelines. Done. Notes:
      • Identifies some of the disabilities compliance will help overcome as “blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity, and combinations of these”.
      • Identifies targeted content as “web content on desktops, laptops, tablets, and mobile devices”.
      • Claims accessibility often promotes:
        • Usability for “older individuals with changing abilities due to aging”.
        • All users.
      • References other documents for content excluded from this one.
      • This in-process version of WCAG 2 anticipates WCAG 3. Discussion of WCAG 3 as of 2018-01 is processual and contains no description of any specific change it is likely to introduce.
      • Defines 3 “levels” of “conformance”: A (minimum), AA, and AAA (maximum).
      • Perceivability:
        • Text is the pivot for making content perceivable. If content is not text, make it available as text, so agents can re-render it in any required form. Alternatively, if necessary, describe it with text. Levels:
          • A: text for graphics and audio; text or audio for video.
          • AA: text for live audio; audio (not only text) for video.
          • AAA: sign language for audio; “extended audio description” (audio with necessary pauses in video) for video; documentary rendition of video, synchronized media (2 or more media in sync), and live audio.
        • Content marked up compatibly with common assistive agents, so they can interpret and reorganize content as needed.
        • Content’s character not perceivable with only a single sense.
        • Any control that serves any of 66 enumerated purposes, named “common control purposes” (45 general ones + 21 input ones), marked up so common assistive agents can interpret it as serving that purpose. Applies also to info explaining the control’s purpose in its context.
        • Media amenable to user manipulation so user can prevent or stop interference between them or modify their magnitudes (color, contrast, font size, simultaneous or background audio, width, justification, spacing).
        • Tooltips etc. stay alive until user dismisses them, and dismissal does not require changing hover or focus.
      • Operability:
        • All functions performable with keyboards.
        • No timing requirements for keypresses. If any, then user can change deadlines.
        • Any nonstandard keyboard action required for focus change explained to user.
        • Motion (including animations, blinking, flashing, updating, interruptions) stoppable.
        • Resumption of session after authentication expires loses no data.
        • Inactivity up to 20 hours loses no data, unless user has been warned.
        • Authentication does not require recall or transcription.
        • Any flashing has a period longer than 1/3 second.
        • Repeated content bypassable.
        • Page titles, headings, labels descriptive.
        • Link purposes programmatically determinable.
        • Focus sequence satisfies intended purpose.
        • Current focus visible.
        • Current page’s place in site visible.
        • Keyboard shortcuts customizable.
        • Each control’s name attribute is or starts with the visible text of the control.
        • Multiple simultaneous pointing not necessary.
        • No irreversible result of a mouse-down.
        • Pointer targets at least 44•22 CSS pixels.
        • Users may choose and change input mechanisms.
        • Behavior can be made independent of device motion and orientation.
      • Understandability:
        • “The default human language of each Web page can be programmatically determined.”
        • Same for “each passage or phrase”.
        • Definitions or disambiguating pronunciations for unusual words and abbreviations made available.
        • Difficulty not exceeding lower secondary-school reading ability.
        • Changed foci or control settings or involuntary events don’t change context.
        • Consistency in navigation-aid placement and component identification.
        • User can get status from assistive devices without changing focus.
        • Users helped to discover, understand, and correct input errors, with any important consequences subject to user confirmation and undoing.
        • Contextual help available.
      • Robustness:
        • Compatibility with assistive technology maximized.
        • Standard code syntax obeyed.
        • Functions (roles) of components programmatically determinable.
      • Conformance:
        • Subpage or subprocess conformance not claimable.
        • Interoperatibility with available assistive technology required.
        • No interfering components that can’t be disabled.
        • Required elements of claims of conformance (including dependencies, testing methods).
    • EN 301 549: Accessibility requirements suitable for public procurement of ICT products and services in Europe. Done. Notes:
      • For Web pages, requires elements to achieve WCAG 2.0 conformance at particular levels.
    • Accessible Rich Internet Applications (ARIA) Working Group, WAI-ARIA Overview. Done. Notes:
      • “WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state. WAI-ARIA describes new navigation techniques to mark regions and common Web structures as menus, primary content, secondary content, banner information, and other types of Web structures. For example, with WAI-ARIA, developers can identify regions of pages and enable keyboard users to easily move among regions, rather than having to press Tab many times.”
    • Accessible Rich Internet Applications (ARIA) Working Group, WAI-ARIA Authoring Practices 1.1. Done. Notes:
      • “Languages used to create rich and dynamic web sites, e.g., HTML, JavaScript, CSS, and SVG, do not natively include all the features required to make sites usable by people who use assistive technologies (AT) or who rely on keyboard navigation.”
      • “ARIA roles, states, and properties are analogous to a CSS for assistive technologies.”
      • Do not specify a role without fulfilling its promise.
      • “Accessibility semantics” = info about UI purposes & meanings for assistive devices.
      • Methods for labeling accordions, alerts, dialogs, breadcrumbs, buttons, checkboxes, combo boxes, disclosures (show/hide buttons), feeds (sections that load articles as scrolling occurs), grids (directionally navigable containers), links, listboxes, menus, menu buttons, radio groups, sliders, spinbuttons, tables, tabs, toolbars, tooltips, tree views, window splitters, and landmark regions (asides, footers, headers, mains, navs, sections, banners, complementary regions, contentinfos, forms, main regions, navigation regions, regions, and search regions).
      • Recommends using native HTML elements instead of corresponding ARIA ones (such as table).
      • If landmark regions are used, no content should be regionless.
      • Standards for providing keyboard interfaces to elements not natively having them.
      • Adopts convention that tab and shift-tab keys move focus across controls, and arrow keys move focus within controls that are groups (“composite widgets”).
      • Focus movement must be predictable.
      • Focus must be distinct from selectedness.
      • Decision on whether selection automatically obeys focus must consider user expectations.
      • Make disabled controls unfocusable only if OK to exclude them from screen readers.
      • Assign conventional keyboard commands.
      • Document grid properties not otherwise discoverable. This includes current column sort orders.
      • Regulates effect of presentation (i.e. none) role, e.g. conditions under which an element with that role forces its children to have it.
    • Transitional recommendations: In the long run plan to use HTML semantic elements for structure representation, with h1–h6 heading elements relative to them (i.e. h1 can be the first heading in each section). But as of now user agents don’t fully recognize HTML semantic elements, so it is most robust to represent the structure dually, both with those elements and with heading elements. E.g., a subsection could begin with an h2 element, a subsubsection with an h3 element, etc. Comment about this.
  • Study history and forecasted future of U.S. federal laws, non-U.S. laws, and standards.
    • U.S. Done. Notes:
      • NFB v. Target, 2006, made websites of places of public accommodation liable for discrimination against disabled, e.g. the blind.
      • “Lawyers anticipate that the Department of Justice will soon amend the Americans with Disabilities Accessibility Guidelines (ADAAG) to include requirements for information and communication technology.”
      • U.S. Dept of Justice formulated new rules starting in 2010 imposing accessibility requirements on websites of private places of public accommodation and state and local governments under the ADA. The department withdrew both rules “for further review” on 2017-10-31. Both are now classified as “inactive”. Commentators have discussed the effects of this change on web accessibility. Some claim that it will encourage disabled advocates to use litigation as the remaining method for obtaining accessibility. Some advise owners of such websites to make them accessible to avoid such litigation, notwithstanding the lack of new regulations. Such lawsuits have been won against Target and Winn-Dixie. Numerous web-accessibility lawsuits have reportedly been filed against credit unions.
    • Non-U.S. Done. Notes:
      • Australia, Canada, Germany, France, Spain, Ireland, New Zealand, and India have imposed WCAG 2 on government websites. This seems to be a common pattern.
      • Ontario as of 2016, Israel as of 2013, and Italy as of 2005 impose the same requirement also on websites of public-facing and/or large private firms.
      • “Increasingly, national policies and global standards are moving towards mandating accessibility in financial services, especially electronic and digital services.” Global Initiative for Inclusive Information and Communication Technologies, Inclusive Financial Services For Seniors and Persons with Disabilities: Global Trends in Accessibility Requirements, 2015.
      • “More than 50 percent of countries worldwide have already expanded the definition of accessibility in their legal frameworks to embrace ICT, including mobile, Internet, computers, video programming, services using digital interfaces, and assistive technologies. That is a 61 percent increase between 2012 and 2014. We expect this global trend toward greater legal definition of accessible ICT and policies to promote broader digital inclusion of persons with disabilities to continue worldwide.” Accessibility Worldview by G3ict.
    • Standards. Done. Notes:
      • Standardization’s main obstacle is technological change. E.g., touch screens not anticipated by WCAG 2.
      • But technological change also may decrease the need for accessibility measures by emulating human users in understanding digital resources and converting that understanding to structured forms that assistive devices can re-render. E.g., INFOBOT Grand Challenge.
      • Computer accessibility measures have existed since 1987 or before.
      • One forecast is that accessibility technology will be forced to become more infrastructural, because otherwise general technological change will outrace assistive technology, in practice retarding accessibility. One initiative to build an accessible infrastructure is the Global Public Inclusive Infrastructure (GPII). It is based in part on a standard for the description of user preferences, enabling automatic adaptation of information resources to satisfy them.
  • Study accessibility techniques of W3C. Done. Notes:
  • Start studying accessibility tools recommended by Austin Cheney and CSU.
    • Siteimprove Accessibility Checker. Finds b element instead of strong element where aXe does not.
    • aXe. Finds iframe without title attribute where Siteimprove and WAAD do not. Claims an id value is not unique, although it is.
    • Accessibility Developer Tools.
      • Accessibility audit (Chrome extension). Finds all tests passed where Siteimprove and aXe find defects.
      • Accessibility Properties pane of Elements tab in Chrome Developer Tools. Finds accessibility-related attributes of elements.
    • Developer Accessibility Tool. Dead.
    • WCAG Accessibility Audit Developer UI Chrome extension. Finds invisible but focusable element where Siteimprove, aXe, and ADT do not. Finds bad color contrast. Finds no other defect. Gives credit for labels for 3 segments of telephone number, though labels are “###” etc., and “Phone” and “phone-area-code” etc. are not labels. Confusing use of icons to convey meaning.
    • Accessibility Feedback Tool Chrome extension. Unusable with https, so unusable.
    • OpenWAX Chrome extension. Reports no errors except link purposes. Reports headings and frames titled, although they are not. No description of why link purposes are allegedly defective.
    • Websites Accessibility Chrome extension. Apparently an authoring tool to add user adjustability to sites, but instructions incomprehensible.
    • Tenon Check for Chrome. Finds only 1 bad link where other tools find other defects. Commercially licensed Tenon API also exists.
    • Alix Chrome extension. Complains about missing for attributes on labels that contain their controls and therefore do not need for attributes. Misses everything else.

Work plan for week of 2017-01-08 to 2017-01-12

Project management: https://trello.com/b/TFJsYKhx/isq

Goals

Respond to requests from the ESLint core team

  • Make requested changes in, and answer questions about, PR 9581.
  • Await approval and merging before completing work on issue 6251.

Continue remediating my weakest IQ element and then demonstrate knowledge thereof

  • Blog about main facts discovered during prior week’s work. Done.
  • Continue studying accessibility tools recommended by Austin Cheney and CSU.
    • Khan/tota11y: Requires modifying website code, so hard to use on others’ sites.
    • A11y.css: Requires modifying website code, so hard to use on others’ sites.
    • Visual ARIA: Installation and use complex. Appears to apply only to software being developed.
    • AInspector Sidebar: Compatible only with obsolete version of Firefox.
    • Chrome Developer Tools Audits Accessibility: Warns of contrast and skip-link issues, similar to aXe.
    • HTML_CodeSniffer: Straightforward to use, but gives only warnings where errors exist and does not identify the elements generating the warnings. Thus, impractical if you give it a large amount of code to analyze.
    • WCAG-Zoo: Python-based. Seems useful only on one’s own code.
    • addyosmani/a11y: Easy to install and run, but returns only 1 passed test where errors exist. Passed-test report refers to “this element” without identifying it.
    • yargalot/grunt-accessibility: Installation instructions refer to “your project’s grunt file”, suggesting it applies only to one’s own code and only under some conditions.
    • nature/pa11y: Tool for HTML CodeSniffer. Currently pa11y. Generates SSL handshake errors on some https sites. May require that phantom.js be run with SSL errors ignored for those sites. Can be run without installation as npx pa11y ….
    • The A11y Machine: Relies on HTML CodeSniffer, but outputs reports informatively, with prioritization of errors over warnings and notices. But heads output with misleadingly specific URL. Misses errors (e.g., color contrast) caught by Siteimprove.
    • TENON: Misses errors caught by Siteimprove. Commercial, priced. Gives suggestions omitted by other tools (e.g., label layout tables with a role).
    • Tanaguru and Asqatasun: Require JDK, JRE, MySQL, Tomcat, Xvfb, Firefox, Postfix.
    • WAVE Chrome extension: Somewhat confusing interface, but finds errors not found by others (e.g., advising that p elements that appear to be headers should be marked as such by being converted to h… elements).
    • Remaining Cheney references: not code audits.
    • Web Developer: Merely executes WAVE. Also has other, non-accessibility, tools.
    • Firebug: Obsolete.
    • Colour Contrast Analyser: Windows-specific. Takes color-spec input, not URLs.
    • Juicy Studio Accessibility Toolbar: Limited to WAI-ARIA live regions, roles, and properties; data tables; and colour contrast. Limited to Firefox.
    • University of Illinois Functional Accessibility Evaluator 2.0: No installation required. Gives extensive details of errors and remediation techniques linked to specific elements. Names elements that are hidden, but refuses to assess them. This can limit its value for single-page sites with dynamic display modification.
    • W3C Internationalization Checker: Finds no problem in a site that embeds all text content directly in the DOM.
    • Sitecues: Overlay for any website adding accessibility features. Commercial. Prices not disclosed.
    • A11Y Project templates: See next item.
  • Discover and, as appropriate, engage with organizations participating in a11y work:
    • A11Y Project. Ruby-based site code, but JS-based code fragments and many HTML/CSS/JS examples acting as templates for accessible constructions. Submitted PR for doc improvement. Merged within minutes. Extensive references to literature. References to tools emphasize color-blindness, thin on other aspects.
    • Other organizations.
      • Raising the Floor. Mission is “to ensure that everyone who faces accessibility barriers due to disability, literacy, digital literacy, or aging, regardless of economic resources, can access and use the Internet and all its information, communities, and services for education, employment, daily living, civic participation, health, and safety.”
      • Lighthouse International: Publishes 1 guide.
      • WebAIM: Has mailman-powered discussion forum. Subscribed.
      • International Association of Accessibility Professionals: Memberships $185/year. Job board, but very sparsely populated. Certification tests, but not for only digital accessibility. Discussion forum for members.
      • Knowbility: Sponsors OpenAIR 5-week hackathon that assembles developer teams to improve accessibility of websites of nonprofit orgs; $150 to participate. Requires weekly face-to-face meetings with client orgs. Focus is Austin TX.
      • Accessibility SIG: Subscribed. 309 members. But nothing posted there since March 2017.
      • Bay Area Accessibility and Inclusive Design: 1200 members. Meets monthly, alternating between Peninsula and SF.
      • IBM: Extensive tools and documentation for developers.
  • Check my own relevant portfolio applications for accessibility and record how they perform. Checked with Functional Accessibility Evaluator 2.0 and Siteimprove (violation scores shown in that order).
  • Start making one or more of these applications more accessible and document methods and results.
    • Calculator
      • Added lang attribute to html element. Chose zxx.
      • Replaced div with h1 for result cell and h2 for button cells. This conflicted with normalize.css, which treats h1 and h2 as styled, not as semantic. Removed normalize.css to eliminate this interference. This may increase inter-browser variation.

Work plan for week of 2017-01-16 to 2017-01-19

Project management: https://trello.com/b/TFJsYKhx/isq

Goals

Respond to actions of ESLint core team, if any

This plan assumes that there will be no such actions this week. If there are any, the plan will be revised accordingly.

Continue demonstrating and increasing knowledge of my weakest IQ element

  • Calculator
    • Finish debugging changes made last week. Done.
    • If that is impossible, start again from master incrementally and test after each change, to catch bugs as they are introduced, using gh-pages as a destination.
    • Document the accessibility improvements. Done.
  • Other applications
    • Decide whether to upgrade other existing applications and, if so, which. Done: Postpone other existing apps.
    • Execute this decision. Done: Nothing to do.
  • Blog about accessibility upgrades. Done (twice).
  • Plan development of a new application with accessibility as its main feature. Done.

Work plan for week of 2017-01-22 to 2017-01-26

Project management: https://trello.com/b/TFJsYKhx/isq

Goals

Respond to actions of ESLint core team, if any

This plan assumes that there will be no such actions this week. If there are any, the plan will be revised accordingly.

Continue demonstrating and increasing knowledge of my weakest IQ element

  • Develop new application with accessibility features.

    • Name: jsonresume-theme-accessible.
    • Purpose: Generate an accessible web page from a file complying with the jsonresume standard.
    • Demonstration: Demonstrate results on my own jsonresume-format curriculum vitae.

  • Blog about week’s accessibility work.

Work plan for week of 2017-01-29 to 2017-02-02

Project management: https://trello.com/b/TFJsYKhx/isq

Goals

Respond to actions, if any, of ESLint core team on PR #9581

This plan assumes that there will be no such actions this week. If there are any, the plan will be revised accordingly. Result: There were no such actions.

Refactor and publish jsonresume-theme-a11y.

  • Refactor code to simplify, generalize, consolidate, and separate. Includes separating view functionality so any future extension from HTML rendering to other formats (e.g., PDF, Markdown) can modify a distinct code unit.
  • Finish README documentation.
  • Publish to NPM.
  • Verify availability of theme to jsonresume users.

Result: Refactoring still incomplete at end of period. Remaining goals postponed to following week.

Attend meeting of Bay Area Accessibility and Inclusive Design.

Result: Attended. Had opportunity to announce availability of Learners Guild apprentices for employment. Witnessed presentation on WCAG 2.1.

Talk with Ashley Harting (HR Generalist) of Level Access.

Done. Led to appointment for telephone meeting with hiring manager Mike Schutte on 2018-02-05.

Respond to suggestions for improvements in calculator.

  • Incompatibility with IE11.
  • Lack of single-input clear-all operation.
  • Potential addition of 1 more button row for memory, exponential, log, and/or trig operations.

Result: Postponed to following week.

Evaluate possible conversion of search engine in DocSearch from Solr to ElasticSearch.

Result: Postponed to following week.

Blog about week’s work.

Result: Postponed to following week.

Work plan for week of 2017-02-05 to 2017-02-09

Project management: https://trello.com/b/TFJsYKhx/isq

Goals

Respond to actions, if any, of ESLint core team on PR #9581

This plan assumes that there will be no such actions this week. If there are any, the plan will be revised accordingly.

Refactor and publish jsonresume-theme-a11y.

  • Finish refactoring code to simplify, generalize, consolidate, and separate. Includes separating view functionality so any future extension from HTML rendering to other formats (e.g., PDF, Markdown) can modify a distinct code unit.
  • Finish README documentation.
  • Publish to NPM.
  • Verify availability of theme to jsonresume users.

Talk with Mike Schutte (Director of Accessibility Services) of Level Access.

Done. Results: He recommended further skill development to qualify for positions there, i.e.:

Respond to suggestions for improvements in calculator.

  • Incompatibility with IE11.
  • Lack of single-input clear-all operation.
  • Potential addition of 1 more button row for memory, exponential, log, and/or trig operations.

Evaluate possible conversion of search engine in DocSearch from Solr to ElasticSearch.

Blog about last week’s and this week’s work.

Work plan for week of 2017-02-12 to 2017-02-16

Project management: https://trello.com/b/TFJsYKhx/isq

Goals

Respond to actions, if any, of ESLint core team on PR #9581

This plan assumes that there will be no such actions this week. If there are any, the plan will be revised accordingly.

Refactor and publish jsonresume-theme-a11y.

  • Test and debug refactored code.
  • Create module or function to convert jsonresume standard source files to jsonresume-theme-a11y format.
  • Publish to NPM.
  • Verify availability of theme to jsonresume users.
  • Get testers.

Respond to suggestions for improvements in calculator.

  • Incompatibility with IE11.
  • Lack of single-input clear-all operation.
  • Potential addition of 1 more button row for memory, exponential, log, and/or trig operations.

Evaluate possible conversion of search engine in DocSearch from Solr to ElasticSearch.

Blog about last week’s and this week’s work.

@judytuna
Copy link

👍 and looking forward to the blog post =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment