Shawn: what we're doing today is going through these tips and consider if we want to include or exclude specific tips. ... and record any thoughts on why we might want to or not include this tip
[reminder: Criteria/Considations for Tips to include]
<shawn> current http://w3c.github.io/wai-quick-start/writing.html#use-headings-to-convey-meaning-and-structure
<shawn> github 62 http://w3c.github.io/wai-quick-start/writing.html#use-headings-to-convey-meaning-and-structure
<shawn> 147 comment https://github.com/w3c/wai-quick-start/pull/147
<shawn> 147 edit https://github.com/w3c/wai-quick-start/pull/147/files
<shadi> [ like rewrite ]
Shawn: point not captured - when
you have a whole lot of text want to add headings ...
... to break up sections of text.
<shadi> [[ "Headings should be short and clearly introduce the section." ]]
Kevin had something like "break into manageable chuncks" ...
<shadi> +1 to separation aspect - but could be just 1 world (in addition to skimming, which is also a good point)
scribe: which gets at the right idea but not quite there.
Kevin: what doesn't it capture sufficiently well?
<shadi> [[ "Use clear and simple headings to break up long passages of text and help readers skim it." ]]
Shawn: "Manageable chunks is not clear enough"
Kevin: What's not caught by "manageable chucks" - what' not conveyed?
Shawn: Manageable by who?
<shadi> [[ dislike "chunks" - seems a bit colloquial or too casual ]]
<Andrew> [[ ... to organise the sections or topics within an article or document.]]
<shadi> [[ "Use clear and simple headings to separate long passages of text and help readers skim it." ]]
Kevin: trying to avoid pushing the "why" of it.
<shadi> [[ "Use clear and simple headings to separate long passages of text and help readers skim the content." ]]
Shawn: Agree, don't want to push "why" we're advocating this - however in this case it might help explain what to do
<Andrew> [[ "Use clear and simple headings to separate and organise long passages of text and help readers skim it." ]]
Shawn: If I were talking casually, I would say when you have a new topic or train of thought, implement a heading - to make it easier for understanding and skimming
<Brent> [[...to split up text into manageable topics.]]
<Andrew> [[Headings break long passages content into more manageable sections and identify what those sections contain.]]
<kevin> [[For example, 'use clear and simple headings to split up text when changing focus or introducing a new idea']]
Kevin: think I've received enough to understand the concerns - kind of subtle.
Shawn: it was a difficult one to articulate.
<shawn> https://github.com/w3c/wai-quick-start/issues/114
Andrew: If we rank something as something 12, we might want to consider dropping it.
Reinaldo: I think this is an important tip.
<kevin> +1
Brent: When talking about providing form instructions and errors, specifically about errors, would the designer or developer know more about specific error correction instructions since they know the program?
<shadi> [[ suggest not focusing this on forms too much - maybe more generally to provide clear guidance where action is required, such as forms ]]
Brent: Would they be better versed to write this content. Does this also apply to the instructions for forms? Or would it still come from the content writer?
<Andrew> possible +1 to Shadi
<shadi> [[ agree with brent - error messages seems out of scope ]]
Kevin: I have to be very
conscious that the activity is about writing. Writer may take
input from the developer or designer but task is writing.
... but maybe one that is moved to another role later but for
now this is a writing activity.
Brent: with that consideration, agree that the task is writing, regardless of role.
<shadi> [[ recall requirements doc was focusing primarily on non-technical writers - typically a CMS user - we should avoid scope creeping and trying to address too much at the same time ]]
Andrew: Shadi's suggestion in IRC not to focus so much on forms but on providing instructions, such as on forms, is a good one.
Shawn: would be good to start a list of items such as this for items that might fit into more than one role or might fit into a different role.
<shawn> https://github.com/w3c/wai-quick-start/issues/120
Shawn: Any reasons to or not include this tip?
Andrew: come across lately where people try to get stuff on the screen, making it harder to skim and parse.
Shawn: not sure it's worth it's own item.
Kevin: maybe related to keeping content clear and concise
Shadi: agree with shawn - not
sure if it constitutes a tip in itself. Not sure to which SC it
would map to.
... I could something more general. Use proper lists when long
sentences, etc. That could map to some SC for
understandability.
... I think if we lift out all the writing techniques, going to
have too many items.
Andrew: Would like to leave it there but drop it off if it has a high number on the list.
Shadi: suggestion is to make it more general - too specific at this point.
Shawn: Andrew, can you think of something broader or something more concise?
Andrew: it's really about
readability.
... What's 3 - make content readable and understandable.
Shawn: it's also about headings in a way. Make it easy to skim.
<Andrew> Guideline 3.1 Make text content readable and understandable
Kevin: Maybe something like "write in a way that's readable and understandable"
Shawn: regardless of skimming, headings and lists make it easy to read and understand, aside from skimming.
Shadi: What about punctuation?
Spelling and grammar checking - those are all writing
techniques. If we list all individual techniques, we'll wind
up
... with a tutorial. Can we lump these things together so that
this is proper writing.
... For example, pointing out need for proper punctuation,
headings, etc.
Lydia: Looking at lists, I think having it as an example, might tell developers how to implement lists, such as ordered and unordered lists.
<Andrew> also falls within - Info and Relationships: 1.3.1 Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. - this more for developers/coders
Lydia: besides keeping content clear and concise suggestion for writer, could tie it in the developer - putting info into lists.
Shawn: wonder if lists fit into clear and concise.
<shawn> Write in short, clear sentences and paragraphs, as appropriate for the context. Front-load important messages. Split complex prose into a few short sentences. Try and keep paragraphs to a single idea.
<Andrew> http://w3c.github.io/wai-quick-start/writing.html#keep-content-clear-and-concise
Lydia: might be good to have lists as a separate point.
<Zakim> kevin, you wanted to suggest a tip based around evaluating
Kevin: I wonder instead of
fitting into "clear and concise," instead have it under a type
of evaluation, such as,
... check your punctuation, etc.
Shawn: shouldn't go into
evaluation. In writing tips, using lists when appropriate
shouldn't be part of evaluating your writing. Should come
before that.
... Andrew, your thoughts - does it fit into a broader tip?
Andrew: don't think it goes into
clear and concise because that's about writing style,
etc.
... could go into reading level, abbreviations.
Shawn: brainstorm - one tip for
complex words and phrases and lists?
... and also acronyms.
Shadi: combinging them might be good.
Andrew: already have an acronym tip proposed.
Shawn: acronym such a minor point
might not make sense to have it as it's own tip.
... so might want to group it under "complex words, lists,
etc."
Andrew: agrees.
Shawn: any reactions, Kevin?
Kevin: have complex words as own
tip. Decision was to keep it separate.
... I wonder if there's a bit of miscellaneous in this. I have
a sense it's a bit of a catchall.
Shawn: "Make text readable" would be a way to include these more minor points we would like to mention but don't warrant their own separate tip.
Kevin: don't know if the number of tips in writing is problematic.
Shawn: not so much the number but level of importance. I.e. having something like acronym have its own tip.
Kevin: can't see the shape of this tip.
Shawn: Andrew, any ideas on what this might look like.
Andrew: In gov't docs, acronyms
used very heavily. Newspapers tend not to. STEM and gov't
writing tend to use a lot.
... Writers tend to assume everyone understands the language
they use.
Shawn: Andrew, you have quickref up, what are items related to readability.
Andrew: Language of the page, unusual words - talks about definiing these, reading level, prononciation.
Shawn: would like to propose a new tip that's generally about readability that includes: complex words, acronyms, , list format, and reading level.
Kevin: my concern they are
grouped that way because that's how they appear in WCAG but may
not be best to group when
... advising someone new to writing for the web.
... Maybe difficult to create an introductory and concise tip
of these grouped items.
Shawn: another perspective - good way to mention a bunch of items that are important but that don't necessarily warrant their own tip.
Shadi: Don't see it as miscellaneous.
Andrew: lists could go under organizingthe content.
Shadi: could slice and dice in many different ways. Should approach it based on how people write.
Shawn: amend my comment - if
going to group a bunch of these under one item. Headings,
transcripts, are separate items.
... Could say this one is "Make Readable and Understandable"
with 5 sub points. Either that or have separate tips.
Kevin: what about adding a tip for "Readability"
<shadi> +1
Kevin: might explore how you have an appropriate reading level and what to do for that.
Shawn: would this be a totally
separate tip or a general concept with sub points.
... what's other's idea of grouping those tips related to
writing style?
Brent: thought structuring with sub tips would make the page harder to read and follow.
Lydia: would incline to agree with Brent. Would make the page more cluttered.
Shawn: do you have another concept - leaving the tips we have here - but adding another one?
Kevin: something around considering the readability of your text.
Shawn: what would it include - would anything existing already be included.
Kevin: I would need to take a look at it.
Reinaldo: at 1st comfortable with grouping small sections but after hearing discussion, I think we need more details about each of these items.
Shawn: leaning towards another tip that would include "lists and readability" or "reading level."?
Kevin: my initial idea is how to make content more readable.
Shawn: my concern is that 3 of what we already have - clear and concise for example - already address this.
Shadi: my understanding or
thought - we'd have "make your writing readable and
understandable" with bulleted lists underneath.
... would also point folks to quickref and SC.
Shawn: to review - on tip about readability and understandibility with bullet items ...
Shadi: important to include the importance of images for conveying information.
Kevin: wasn't what he had in mind. This is grouping a number of tips and not having explanations and examples.
Shawn: Shadi had said one
sentence. But I think bullet can be a few sentence.
... currently, I think there's too much explanation there in
the individual tips.
Andrew: I'm of the opinion that providing clear tips for writers is just as important as providing specific coding tips is for developers. Hate to see baby out with bathwater.
Shawn: I'm thinking that grouping may help with conveying this information.
Andrew: as long as we don't lose the important details.
Kevin: afraid that by grouping, we lose the summary at the top and will lose detail that helps people understand what the tip is about.
<Andrew> I meant group like tips in the menu (rather than as a big tip)
Shadi: clear we're having this
discussion because looking at needs analysis, scope, is to
provide initial tips. Temptation is to expand on what we cover.
Where do we draw tthe line regaring detail?
... Think Shawn has a good point. Will this resource have more
impact if group a number of these tips under a larger concept
or if we go into detail. Danger is re-writing WCAG.
Shawn: propose for next step for
Kevin - I'm willing to help - is for Kevin to draft a tip that
combines readability and understandability.
... and that existing separate tips under this category would
go away.
<shawn> http://w3c.github.io/wai-quick-start/writing.html
Shawn: 13 July survey closed on these tips. Any concern with including any of these?
Shawn: shifting to Developing tips.
<Andrew> existing developing tips - http://w3c.github.io/wai-quick-start/developing.html
<shawn> https://github.com/w3c/wai-quick-start/issues/146
Reinaldo: important topic to consider for ESL but good tip to insert in developing piecel
Shawn: pros, cons?
Lydia: for it.
Andrew: concurs - reminds folks its a WWW not an English Wide Web.
Kevin: concern is that it's a
one-liner.
... no problem with including it as a concept an seeing how it
stacks up with all the others.
<shawn> https://github.com/w3c/wai-quick-start/issues/152
<Reinaldo> +1
Shawn: suggesttion is that we
need to include table markup, either as separate tip or include
in tip about convey meaning through markup.
... one option is separate tip, one to not mention at all, or
to include under "use markup to convey meaning and
structure.
<shadi> +1
<Andrew> lots of detail in http://www.w3.org/WAI/tutorials/tables/
Shawn: comfortable putting it as separate tip and then linking to table tutorial.
Kevin: agree - a lot that goes into table markup - would be hard to convey with a short concise tip,
Shawn: will not include table markup as separate tip but under convey with markup.
<kevin> https://github.com/w3c/wai-quick-start/issues/156
<Andrew> http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html
Shawn: do we want to say anything about developing sites so that uses can resize text?
Kevin: relates a bit to the tip on responsive design.
Andrew: related but a different issue.
Shawn: if we were to address it separately, what things might we say?
Andrew: when web text is resized want to avoid horizontal scrolling.
Kevin: also overlapping.
Reinaldo: wonder if this should
go under designing or developing.
... wonder if designer should consider the affect of resizing
text.
Shawn: could you do a quick draft
of something so that we have something for rating.
... because of open issues, may not be ready for the survey on
developing.
... proposal - Kevin will do a quick write-up so that people
can rate it.
<kevin> https://www.w3.org/2002/09/wbs/35532/EOWG13July2015/results#xdev
Kevin: no GitHub issue yet.
Shawn: Kevin, can you add to dev'l so that we get a rating on it.
Kevin: the WBS survey has a reference to it.
Shawn: any comments on whether we want this in developing.
Andrew: prefer dev'l doesn't create the alt text. If decorative image should be conveyed through the CSS and also maybe the situation where an image is a link adjacent to identical linked text.
https://github.com/w3c/wai-quick-start/issues/159
Lydia: agree this would be a good topic.
Shawn: how much is a developer vs. user interface designer?
Kevin: I would be hesitant to
include as a tip, even though they are a big problem.
... this is tutorial level topic vs. tip level. Lot's of
approaches and alternatives. Would wonder what it would say
besides
... avoid using CAPTCHA if you can.
Shadi: kind of with Kevin but
what would the tip really say.
... or if it could be merged in images.
Shawn: don't see it with images. don't have one good place
to point people to. What would we say?
... Could just raise awareness. Another perspective: this is
tips for getting started but this is too complex for the scope
of "Tips".
Lydia: would have tip say CAPTCHA should include both audio and visual.
<kevin> https://github.com/w3c/wai-quick-start/issues/118
<shadi> [[ shawn's point: is a tip _important_ vs _relevant for getting started_ ]]
Kevin: not 100% certain of Eric's
concern. Didn't get a chance to discuss with him.
... Suggested that should be something that also points dev'l
to evaluation tools.
... I've suggested that we have a tip for dev'l to use
evaluation tools for checking code.
... Core is, as a dev'l, make sure you use evaluation tools to
check your code/site
Shadi: I think Eric is reacting
to the validation aspect. People would run site through
validator and receive an error - causing them to think
... their site is inaccessible. This is not something required
by WCAG.
Shawn: I have a separate issue. We shouldn't have a tip that says evaluate your code. Not a WCAG requirement.
<kevin> Related to: https://github.com/w3c/wai-quick-start/issues/154
Shadi: some level of validation is required to find compatibility and accessibility problems.
https://github.com/w3c/wai-quick-start/issues/26
[After the meeting, Kevin and Shawn noted that this could be woven into an existing tip in Designing, and not included in Developing.]
Shawn: not ready for next survey yet but we'll send an update of things to look at.