Recommended Reading

The Badeyes WordPress Theme is Now Live and Available for Download!

by Geof Collis
December 18, 2014

It has been a long 4 months of researching code and using checking tools but WordPress has finally approved the Badeyes TwentyFourteen Child Theme and it is now live for anyone to download.

Thanks go to the many people on the LinkedIn group, WordPress experts, who helped me solve issues I couldn’t find researching through Google.

A big thanks also goes to my 12 year old daughter who I call my “IT Support”, she is the sight that I dont have in order to notice visual problems such as alignment, I’m sure we still have more work ahead of us but we’ll tackle them as people point them out or she does.

The Theme named “Badeyes” is a Child of the popular TwentyFourteen Magazine style layout but is more accessible and customizable, it can be viewed at https://www.badeyes.com/2014/ and you can see it in action at http://www.accessibilitynews.ca, http://www.aoda.ca and http://www.accessibilitynewsinternational.com.

Creating a Theme is no easy task at first, there is a lot of rules and stipulations you need to know and testing, testing testing, I almost gave up when after 4 months I still had errors I needed to fix, I was tired but figured I’ve come this far, might as well see it through.

Every time an email came from the people who volunteer their time to check Themes my heart would jump!

Was it approved? Was it rejected? Or were their still things to fix?

December 17, 2014 was no different, I actually thought to myself that if they just rejected it I would move on, after all I was already using it on my own sites, but their it was “Congratulations your Theme is now Live”!!

Anyone who knows WordPress can download it through their Dashboard or go directly to it on WordPress at https://wordpress.org/themes/badeyes

I’m working on another Theme right now that I use on my site https://www.badeyes.com but dont know if I have the stamina to see it through.

Again, thanks to all of the good folks on LinkedIn who gave me the benefit of knowledge that I didn’t have in order to see this to its completion!

4.1.2: Name, Role, Value: (A)

For all user interface components (including but not limited to: form elements,
links and components generated by scripts), the name and role can be programmatically
determined ; states, properties, and values that can be set by the user can be
programmatically set ; and notification of changes to these items is available
to user agents, including assistive technologies.
(Level A)

Note: This success criterion is primarily for Web authors who develop or script
their own user interface components. For example, standard HTML controls
already meet this success criterion when used according to specification.

Sufficient Techniques for 4.1.2 – Name, Role, Value

Situation A: If using a standard user interface component in a markup language
(e.g. HTML):

  • 1.G108: Using markup features to expose the name and role, allow user-settable
    properties to be directly set, and provide notification of changes
    using technology-specific techniques below:
  • H91: Using HTML form controls and links
    (HTML)
  • H44: Using label elements to associate text labels with form controls
    (HTML)
  • H64: Using the title attribute of the frame and iframe elements
    (HTML)
  • H65: Using the title attribute to identify form controls when the
    label element cannot be used
    (HTML)
  • H88: Using HTML according to spec
  • SCR21: Using functions of the Document Object Model (DOM) to add
    content to a page
    (Scripting)

Situation B: If using script or code to re-purpose a standard user interface
component in a markup language:

  • 1.Exposing the names and roles, allowing user-settable properties to be
    directly set, and providing notification of changes using one of the following
    techniques:
  • SCR21: Using functions of the Document Object Model (DOM) to add
    content to a page
    (Scripting)

Situation C: If using a standard user interface component in a programming technology:

  • 1.G135: Using the accessibility API features of a technology to expose
    names and roles, to allow user-settable properties to be directly set, and to
    provide notification of changes

Situation D: If creating your own user interface component in a programming
language:

  • 1.G10: Creating components using a technology that supports the accessibility
    API features of the platforms on which the user agents will be run to expose
    the names and roles, allow user-settable properties to be directly set, and
    provide notification of changes

Advisory Techniques for 4.1.2 – Name, Role, Value

  • Providing labels for all form controls that do not have implicit
    labels

Failures for SC 4.1.2 – Name, Role, Value

  • F59: Failure of Success Criterion 4.1.2 due to using script to
    make div or span a user interface control in HTML

Note: This failure may be solved in the future using DHTML roadmap techniques.

  • F15: Failure of Success Criterion 4.1.2 due to implementing custom
    controls that do not use an accessibility API for the technology, or do so incompletely
  • F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating
    text alternatives when changes to non-text content occur
  • F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association
    of label and user interface controls not being programmatically determinable
  • F79: Failure of Success Criterion 4.1.2 due to the focus state of
    a user interface component not being programmatically determinable or no notification
    of change of focus state available
  • F86: Failure of Success Criterion 4.1.2 due to not providing names
    for each part of a multi-part form field, such as a US telephone number
  • F89: Failure of 2.4.4, 2.4.9 and 4.1.2 due to using null alt on
    an image where the image is the only content in a link

http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

4.1.1: Parsing: (A)

In content implemented using markup languages, elements have complete start
and end tags, elements are nested according to their specifications, elements
do not contain duplicate attributes, and any IDs are unique, except where the
specifications allow these features. (Level A)

Note: Start and end tags that are missing a critical character in their formation,
such as a closing angle bracket or a mismatched attribute value quotation mark
are not complete.

Sufficient Techniques for 4.1.1 – Parsing

  • 1.G134: Validating Web pages
  • 2.G192: Fully conforming to specifications
  • 3.H88: Using HTML according to spec
  • 4.Ensuring that Web pages can be parsed by using one of the following
    techniques:
  • H74: Ensuring that opening and closing tags are used according to
    specification
    (HTML)
  • H75: Ensuring that Web pages are well-formed
    (HTML)

Failures for SC 4.1.1 – Parsing

  • F70: Failure of Success Criterion 4.1.1 due to incorrect use of
    start and end tags or attribute markup
  • F77: Failure of Success Criterion 4.1.1 due to duplicate values
    of type ID
  • F17: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient
    information in DOM to determine one-to-one relationships (e.g., between labels
    with same id) in HTML
  • F62: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient
    information in DOM to determine specific relationships in XML

http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html

4.1:Compatible:

Maximize compatibility with current and future user agents, including assistive
technologies.

Advisory Techniques for Guideline 4.1

  • Avoiding deprecated features of W3C technologies
  • Not displaying content that relies on technologies that are not
    accessibility-supported when the technology is turned off or not supported.

http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat.html

4.0: Principle 4: Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

3.3.6:Error Prevention (All): (AAA)

For Web pages that require the user to submit information, at least one of the
following is true: (Level AAA)

  • 1.Reversible: Submissions are reversible.
  • 2.Checked: Data entered by the user is checked for input errors
    and the user is provided an opportunity to correct them.
  • 3.Confirmed: A mechanism is available for reviewing, confirming, and correcting
    information before finalizing the submission.

Sufficient Techniques for 3.3.6 – Error Prevention (All)

  • 1.Following the sufficient techniques for Success Criterion 3.3.4
    for all forms that require the user to submit information.

http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-reversible-all.html

3.3.5: Help: (AAA)

Context-sensitive help is available. (Level AAA)

Sufficient Techniques for 3.3.5 – Help

Situation A: If a form requires text input:

  • 1.G71: Providing a help link on every Web page
  • 2.G193: Providing help by an assistant in the Web page
  • 3.G194: Providing spell checking and suggestions for text input
  • 4.G184: Providing text instructions at the beginning of a form or set
    of fields that describes the necessary input

Situation B: If a form requires text input in an expected data format:

  • 1.G89: Providing expected data format and example
  • 2.G184: Providing text instructions at the beginning of a form or set
    of fields that describes the necessary input

Advisory Techniques for 3.3.5 – Help

  • H89: Using the title attribute to provide context-sensitive help
    (HTML)
  • Checking byte of character and auto-converting to expected byte
    for text input if applicable

http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-context-help.html

3.3.4: Error Prevention (Legal, Financial, Data): (AA)

For Web pages that cause legal commitments or financial transactions for the
user to occur, that modify or delete user-controllable data in data storage
systems, or that submit user test responses, at least one of the following is true: (Level AA)

  • 1.Reversible: Submissions are reversible.
  • 2.Checked: Data entered by the user is checked for input errors and the
    user is provided an opportunity to correct them.
  • 3.Confirmed: A mechanism is available for reviewing, confirming, and correcting
    information before finalizing the submission.

Sufficient Techniques for 3.3.4 – Error Prevention (Legal, Financial, Data)

Situation A: If an application causes a legal transaction to occur, such as
making a purchase or submitting an income tax return:

  • 1.G164: Providing a stated period of time after submission of the form
    when the order can be updated or canceled by the user
  • 2.G98: Providing the ability for the user to review and correct answers
    before submitting
  • 3.G155: Providing a checkbox in addition to a submit button

Situation B: If an action causes information to be deleted:

  • 1.G99: Providing the ability to recover deleted information
  • 2.G168: Requesting confirmation to continue with selected action
  • 3.G155: Providing a checkbox in addition to a submit button

Situation C: If the Web page includes a testing application:

  • 1.G98: Providing the ability for the user to review and correct answers
    before submitting
  • 2.G168: Requesting confirmation to continue with selected action

Advisory Techniques for 3.3.4 – Error Prevention (Legal, Financial, Data)

  • Informing the user what irreversible action is about to happen
  • SCR18: Providing client-side validation and alert
    (Scripting)
  • Placing focus in the field containing the error
  • Avoiding use of the same words or letter combinations to begin each
    item of a drop-down list
  • G199: Providing success feedback when data is submitted successfully

http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-reversible.html

3.3.3: Error Suggestion: (AA)

If an input error is automatically detected and suggestions for correction are
known, then the suggestions are provided to the user, unless it would jeopardize
the security or purpose of the content. (Level AA)

Sufficient Techniques for 3.3.3 – Error Suggestion

Situation A: If a mandatory field contains no information:

  • 1.G83: Providing text descriptions to identify required fields that were
    not completed

Situation B: If information for a field is required to be in a specific data
format:

  • 1.G85: Providing a text description when user input falls outside the
    required format or values
  • 2.G177: Providing suggested correction text
  • 3.SCR18: Providing client-side validation and alert
    (Scripting)
  • 4.SCR32: Providing client-side validation and adding error text via the
    DOM
    (Scripting)

Situation C: Information provided by the user is required to be one of a limited
set of values:

  • 1.G84: Providing a text description when the user provides information
    that is not in the list of allowed values
  • 2.G177: Providing suggested correction text
  • 3.SCR18: Providing client-side validation and alert
    (Scripting)
  • 4.SCR32: Providing client-side validation and adding error text via the
    DOM
    (Scripting)

Advisory Techniques for 3.3.3 – Error Suggestion

  • G139: Creating a mechanism that allows users to jump to errors
  • Making error messages easy to understand and distinguishable from
    other text in the Web page
  • Validating form submissions on the server
  • When mandatory information has not been provided, including descriptions
    or examples of correct information in addition to identifying the field as mandatory
  • Repeating and emphasizing suggestions for correcting each input
    error in the context of its form field
  • Providing a way for the user to skip from each item in a list of
    suggestions to its corresponding form field
  • Providing additional contextual help for the form field requiring
    change
  • Accepting input data in a variety of formats
  • G199: Providing success feedback when data is submitted successfully

Techniques for providing suggestions to the user (Advisory)

  • Providing a text description that contains information about the
    number of input errors, suggestions for corrections to each item, and instructions
    on how to proceed
  • Providing a text description that contains suggestions for correction
    as the first item (or one of the first items) of content, or emphasizing this
    information in the content
  • Displaying errors and suggestions in the context of the original
    form (for example, re-displaying a form where input errors and suggestions for
    correction are highlighted and displayed in the context of the original form)

HTML Techniques (Advisory)

  • Providing “correct examples” for data and data formats
    as initial text in mandatory form fields
  • Providing links to suggested correction text “close to”
    form fields, or providing the suggested correction text itself directly on the
    Web page “next to” form fields

Client-Side Scripting Techniques (Advisory)

  • SCR18: Providing client-side validation and alert
    (Scripting)
  • Providing client-side validation and adding error text via the DOM
  • Calling a function from the submit action of a form to perform client
    side validation

ARIA Techniques (Advisory)

  • ARIA2: Identifying required fields with the “required” property
    (ARIA)
  • ARIA3: Identifying valid range information with the “valuemin”
    and “valuemax” properties
    (ARIA)

http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-suggestions.html

3.3.2: Labels or Instructions: (A)

Labels or instructions are provided when content requires user input. (Level
A)

Sufficient Techniques for 3.3.2 – Labels or Instructions

  • 1.G131: Providing descriptive labels AND one of the following:
  • G89: Providing expected data format and example
  • G184: Providing text instructions at the beginning of a form or
    set of fields that describes the necessary input
  • G162: Positioning labels to maximize predictability of relationships
  • G83: Providing text descriptions to identify required fields that
    were not completed
  • 2.H44: Using label elements to associate text labels with form controls
    (HTML)
  • 3.H71: Providing a description for groups of form controls using fieldset
    and legend elements
    (HTML)
  • 4.H65: Using the title attribute to identify form controls when the label
    element cannot be used
    (HTML)
  • 5.G167: Using an adjacent button to label the purpose of a field

Note: The techniques at the end of the above list should be considered “last
resort” and only used when the other techniques cannot be applied to the
page.
The earlier techniques are preferred because they increase accessibility to
a wider user group.

Advisory Techniques for 3.3.2 – Labels or Instructions

  • G13: Describing what will happen before a change to a form control
    that causes a change of context to occur is made
  • ARIA1: Using Accessible Rich Internet Application describedby property
    to provide a descriptive, programmatically determined label
    (ARIA)
  • ARIA4: Using Accessible Rich Internet Applications to programmatically
    identify form fields as required
    (ARIA)
  • Providing linear form design and grouping similar items

Failures for SC 3.3.2 – Labels or Instructions

  • F82: Failure of Success Criterion 3.3.2 by visually formatting
    a set of phone number fields but not including a text label

http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html