Re: In WCAG NEXT let's put a date field on failures

I understand that.

but the question is — "what are you intending to require in these Breakout SC ?”  .  

it can’t be “Headings must look like headings”   because they will.

It can’t be  “Headings must be marked up as headings”  because not everything is a markup language - or one that is supported by AT. 

So what is it that you intend to say about headings in your breakout SC?   (Without making it technology specific — or being just a  general as WCAG ?) 

that is the question/point.    That is what I don’t understand. 

best 

gregg

> On May 1, 2016, at 2:24 PM, Wayne Dick <wayneedick@gmail.com> wrote:
> 
> Gregg,
> This is conceptual, not literal. The underlying domain of discourse is written language. It has protocols that transcend representational technology.
> 
> Headings, lists, special fonts for emphasis, labels, form boxes and external references all predate HTML technology. They are elements of written language. They existed long before computers. 
> 
> Mark-up language was a technological leap that gave these semantic structures a machine representation that was independent of presentation, and thus identifiable by computer parsing technology (low degree, polynomial time, programmatic determinism). 
> 
> No matter what technology you use for written language (paper, braille, markup language, procedural content) you will find these constructs. Perhaps other technologies use different names, but they must have these constructs if they want to be a communication tool for human writing. WCAG's job is to select neutral yet understandable terminology to describe the elements of written language that must separate meaning from presentation when they are represented on a computer. 
> 
> The functional divisions I meant were the functional divisions in written language.  If we divide data independence along these lines, it will serve all technology that represents written language.
> 
> Wayne
> 
> On Sat, Apr 30, 2016 at 2:50 PM, Gregg Vanderheiden <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote:
> Careful — if you do that you may destroy the technology independent nature of WCAG  — and you make it list based - which makes it always out of date
> 
> 1) list based 
> WCAG currently covers all information provided visually…..
> if you change it to  headings and lists and this and that — then you will always have an incomplete list and the rest is not covered. 
> WCAG says “all" - and then explains what is included (but not limited to ) by the word ‘all’ in the Understanding WCAG 2.0  doc.  You can say   " including but not limited to “ in understanding but not in a standard provision. 
> 
> 2) technology independence.
> if you specify headings need to be x — you are usually referring to constructs in HTML that may not exist elsewhere.   Again WCAG leaves technology specific terms to ‘sufficient techniques for specific technologies — rather that making WCAG tech specific
> Now many technologies may have headings — but they may call them by other names — or there may be other things in addition. 
> 
> I think all of the things you seek below are covered and required by WCAG already.      breaking them out in WCAG instead of Understanding WCAG 2.0  can create the problems above.
> 
> if the problem is that people don’t know that they are covered - then Understanding WCAG 2.0  can do that without needing to change WCAG and risk the above issues. 
> 
> 
> Just saying to think it all the way through before changing the model.   The WG spent a LOT of time (years) trying to make it clearer and more specific without tripping these other issues.   It is REALLY hard. 
> 
> Good luck 
> 
> gregg
> 
>> On Apr 30, 2016, at 4:09 PM, Wayne Dick <waynedick@knowbility.org <mailto:waynedick@knowbility.org>> wrote:
>> 
>> As we look at WCAG Next we might consider criteria like 1.3.1 and 4.1.2 as guidelines. 1.3.1 can be decomposed functionally. There are objects that support navigation like headings. Others support associations of objects (table headers, and table data) as well as labels and controls 1.3.2 could be interpreted as an SC under 1.3.1 e.g. sequences can be programmatically determined. Separation of style from meaning really seems like the core guideline, not the more vague, flexible data.  It gets at the relationship between markup language and accessibility.
>> 
>> I think a functional dissection of this concept into discrete components might be the technology independent way to parse refined semantics for success criteria. 
>> 
>> Wayne
>> 
>> On Fri, Apr 29, 2016 at 1:23 AM, Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
>>  "White, Jason J” wrote:
>> Do you have a proposal as to how you would maintain the technology-neutral and general approach of WCAG 2.0 while providing more normative detail in these areas?
>> 
>> 
>> I wish I did!  I can understand why it was so difficult for WCAG 2. 
>> 
>> I will think about it, my first thought is perhaps separating layout & navigation considerations from content-level widgets, perhaps inline with HTML5’s concepts of kinds of content [1].
>> 
>> I realise that HTML5 is technology specific, but I think other platforms have similar concepts that we can take an high-level view on.
>> 
>> It might even be a case of putting 1.3.1 and 4.1.2 together at the principle level so there is one area for ‘what is this thing and what does it do’.
>> 
>> Cheers,
>> 
>> -Alastair
>> 
>> 1] https://www.w3.org/TR/html5/dom.html#kinds-of-content <https://www.w3.org/TR/html5/dom.html#kinds-of-content> 
>> 
>> 
>>  
>> 
>> For example, HTML and SVG are very different in regard to the kinds of structure that they support, even without considering other technologies which an author might use.
>> 
>>  
>> 
>> The supported structural and semantic distinctions change with each version of one of these languages. HTML may be heading toward a more rapid release process as well, which further accelerates the pace of change.
>> 
>>  
>> 
>> The above is a genuine question; I’m not trying to use it in support of an argument that more detailed success criteria in these areas are infeasible, but neither do I have a good answer – and these are very much the issues that were struggled with when WCAG 2 was under development.
>> 
>>  
>> 
>> 
>> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
>> 
>> 
>> Thank you for your compliance.
>> 
>> 
> 
>