Mobile Accessibility Task Force Teleconference -- 14 Aug 2014

<trackbot> Date: 14 August 2014

Writing techniques introduction (Jeanne)

Jeanne: talking about writing techniques

<jeanne> https://www.w3.org/WAI/GL/wiki/Technique_Instructions

Jean: quick review of the difference between a success criteria and a technique. Success criteria are normative, typically not changed, techniques are informative – they can be changed.

Jeanne: techniques are the parts developers use anyway – when they are looking for something or a problem they go to the techniques
... letters – G for general, then technology specific, H for HTML, Silverlight etc.
... it's important to look at the general techniques because it gives you the style, structure, what belongs in a technique. So we are going to start with editing existing techniques. We have a list of existing techniques

<jeanne> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

Jeanne: this chart is a list of technique assignments – this is on the mobile accessibility task force wiki. Technique, and then linked on the leftmost column to our wiki where people have made notes about that. If you click on G4 in the left-hand column – two G4 links, the first one goes to the mobile accessibility wiki, the second one in the last (right-hand) column goes to the actual...
... WCAG...
... technique
... hasn't been settled yet what letter we will use
... that won't hold us up, but in this example we wouldn't change it because all we are doing for this particular technique is adding an example for mobile use
... proposed having a separate mobile techniques document containing all the updates and new techniques so there's a one-stop document that links to all the mobile. still need to see what happens with that
... example
... suggested example that required tapping on the screen instead of a keyboard command
... using the wiki – click "edit" at the top to add information to page.

For right now – use insert and delete to show what we are adding and what we are deleting.

<jeanne> In Examples, Insert bullet point as follows:

<jeanne> A web page contains a button labeled "How to tie a shoe" which links to a new ...

Jeanne: we would add the changes to our webpages to make it very clear what should be happening to whoever is making the changes. It needs to be very specific, not a general description – the specific language we want to put into the WCAG success criteria

Mike: seeing the page, but not the opportunity to edit

Jeanne: there's a login button, then you will see the edit tab

<jon_avila> Could use @@ before and after changes in text

Open the right-hand column to see the technique, open the left-hand column – that's where the notes go. If necessary, copy a block from the right-hand column to show where the changes go. Use language like "Insert bullet point under examples heading"

judgment call – whether to use language or to copy a block to show changes

<jon_avila> Somewhat familiar

Jeanne: who is familiar with github and can work with it home?

Alan and Jan are familiar with it

Jeanne: I'll keep in mind that people are willing to work and get home – that could streamline things, it could be an option, a mix of both
... Some of the things to think about when you are writing
... link to the technique instructions

<jeanne> https://www.w3.org/WAI/GL/wiki/Technique_Instructions

<jon_avila> Are we going to send these in batches for approval from WCAG WG?

<jon_avila> Thanks

Jeanne: talked to Michael about this, he would like us to send things as they are ready – if we approve one, two or three a week we will send them toWCAG right away
... Technique instructions document is oriented toward people who want to write a whole number of instructions for a specific technology, so some of it is not useful. The technique right up list which is further down on this page is very useful.
... one of them which is not on this list is using vendor neutral descriptions wherever possible. The big place where we are going to run into this is the desire to say "using voice over" or "on the android do this" and there may be places where we have to do this, and there's a place in the applicability section where we can do that, but wherever possible we should look for a technology neut

ral way to describe what to do

Jeanne: for example, instead of saying voiceover we could say voice response

<jon_avila> Voice output

Jeanne: wherever possible we don't want to put ourselves in the position where were saying we are promoting a particular piece of technology. We don't want to give the impression that were saying that android is better than iPhone But if we can't be, there is a section on applicability which allows you to include information about when it is technically appropriate to use the technique

<jon_avila> Would the term "make sure" be good?

Jeanne: Limaook at the techniques write up checklist – please avoid using the words required, must and shall. These have particular meaning in standards writing and because these are informative techniques – you are not required to do these techniques, you can do different techniques and still be WCAG, we don't want to use 2119 language
... decide on a convention for referring to common products and numbers – write notes so we can agree on this as a group
... if you are working on a failure technique, please note the special requirements for failure techniques at the end of the page. There's a lot of careful wording you have to do – if we get into those there's a whole section that describes those

Alan: review process?

Jeanne: we'd like to make this work more asynchronous – we have a number of people in Asia who would like to be helping out with this work but can't make the meeting times. We'd like to, when you finish writing a technique, even if it's only one, send an email to the group list, and Kim or Kathy or I will included on a survey for that week and people can look at the survey, make comments...
... including people who cannot make the meetings, they will be able to comment on the techniques and then we can approve it in the meetings or put it if we want more contribution, we can have people email to the list

<jeanne> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Technique_Template

When sending an email to the list make sure to include a links right to the note pages of what you have done.

So, here's what I've done and here are the links to it

Jeanne: we will be adding to existing techniques and also creating new techniques
... when creating new techniques, use this template
... Template status section: important to include links to discussions, surveys, emails where this has been discussed so when people are going back and trying to figure out reconstructing history of a technique, it's apparent what has happened, especially if time is gone by
... Applicability section: this is where we put examples of where this applies to
... WCAG references section: this one is tricky, they want you to include the anchor for the item, the short name, and whether it is sufficient, advisory or failure. The tricky part is getting the anchor. The best way to get the anchor is to click on the original WCAG link – the right-hand link, then go to success criterion 2.2.1, then you can see there's an anchor (in the case of G4...
... time-limits-required--behaviors) this is going to the document, but gives WCAG the ability to cross reference it
... then you get into the bulk of the technique, which is the description and it always starts with "the objective of this technique is…" Describe what the user should accomplish and then talk about how
... Examples, if needed you can put code samples there, have to manually wrap the lines, have to keep them short
... list of resources, if you want to put in related techniques you can

<jeanne> https://www.w3.org/WAI/GL/wiki/Writing_WCAG_Techniques_-_Notes

Jeanne: writing the test

very detailed notes on the purpose of these – I recommend bookmarking this one

<jeanne> https://www.w3.org/WAI/GL/wiki/Technique_Instructions

Techniques Notes is more simple, Technique Instructions has details

http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Techniques_Resources

Resources page on our wiki has all these links

Jon: to general comments – map techniques to guidelines and not just success criteria? Advisory techniques don't necessarily mean you make basic success criteria.

Jeanne: mapping to guidelines is a great answer to some of the success criteria we came up with that maps to other guidelines – we can include the things that we haven't found a good match for with WCAG success criteria, when they don't match well with a specific success criteria we can map to a guideline elsewhere
... advisory techniques don't necessarily mean you make basic success criteria – that's not something we have to write in

Jon: just think it can be confusing – I've seen some success criteria that don't have a sufficient technique, but seems to have an advisory technique that goes above and beyond it. I'd like to make sure we have a sufficient technique for most aspects of success criteria and also as many failures as possible. In general somethings we are missing

Jeanne: we haven't particularly been writing failures for some of the new things for mobile, or flagging possible failures – would be useful if we add to the table as we see them

http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

<AlanSmith> Jeane, great job. thanks

- DRAFT -

Mobile Accessibility Task Force Teleconference

14 Aug 2014

Attendees

Contents

Writing techniques introduction (Jeanne)

Summary of Action Items

Scribe.perl diagnostic output