Author Accessibility

[cooper.semantics]

Web Accessibility is well known by all but, if there is a misconception of what exactly web accessibility means - http://en.wikipedia.org/wiki/Web_accessibility. Now with everyone on the same page I will get to my point (Author Accessibility). Author Accessibility is not practiced by the majority of web developers.

Author Accessibility includes the following:
1. Naming conventions
2. Correct markup
3. Author notation
4. Validation
5. Components
6. Separation

1. Naming conventions - Naming conventions are a huge asset to a developer. For instance, if you name something left or the famous leftCol then when the time the content is switched over to the right side there is a mass confusion. This causes bad 'author accessibility'. A good example of good 'author accessibility' is related-content or main-content. If these get switched they will still be explaining what they are describing and keeping consistent accessibility.

2. Correct markup - Correct markup is the right markup for the job. If you have a headline followed by a sub-headline for example,
<h2>Paris growing in population</h2>
<p>.....</p>
<h3>Population Statistics</h3>
<p>......</p>
Also, remember that presentation has no part of data. So keep correct markup in mind before thinking presentation.

3. Author notation - Author notation is great in the aspect of telling other developers where certain blocks of coding start and stop as well as telling them what the blocks of coding are. Also, this practice is good for debugging an invalid page. Some times with cluttered coding or templated code the tabbing gets out of line. With author notation this would clear everything up for the author.

4. Validation - Validation needs to be set in stone so that the page is not having issues prior to an unclosed tag or etc. A majority of the time issues for layout happens because of lack of validation. This is one of the most important aspects of 'author usability'.

5. Components - Components are snippets of coding that help the present developer from reinventing the wheel each time. Components also help workload and CSS bulk.

6. Separation - This is the most important aspect of 'author accessibility'. Separating data from presentation and behavior is the key meaning of separation. As mentioned throughout the entire Sitepoint blog, CSS does not need to be mixed with HTML or JavaScript. Mixing data with presentation or behavior is equivalent to the old table-layout era. For instance, if you have 100 pages and within those 100 pages you have 50 with inline styles for the same <ul>, then you would manually have to go back and change them. Instead, if you would have separated the css from the html this would have not been the situation.

[Karpie]

Good in theory, but practical examples are required to flesh it out.

Also, I don't think 'author accessibility' is the right term to use. Good practices maybe, but they have little to do with traditional accessibility.

[cooper.semantics]

Good in theory, but practical examples are required to flesh it out.

Also, I don't think 'author accessibility' is the right term to use. Good practices maybe, but they have little to do with traditional accessibility.

@Karpie -
Accessibility can be viewed as the "ability to access". I feel that author accessibility is correct in how it was used. As I stated before this is not being used by a lot of developers. Good practices could also be pinned to anything and everything because it is too 'generic'. Sorry I can't agree with you on this one

[r937]

when i saw the thread title, i was hoping there would be a discussion of why so many web sites and blogs are anonymous, that "author accessibility" would mean that the author of the web site or blog should be easy to identify (for example, on the About page)

but alas, no

i agree, a better term for your concepts would be a good idea

[AutisticCuckoo]

Be that as it may, I think you've captured some important points there, Cooper.

The importance of #3 may not be as great these days, now that we've got Dragonfly and Firefox, but it's definitely helpful.

[cooper.semantics]

when i saw the thread title, i was hoping there would be a discussion of why so many web sites and blogs are anonymous, that "author accessibility" would mean that the author of the web site or blog should be easy to identify (for example, on the About page)

but alas, no

i agree, a better term for your concepts would be a good idea

Author Accessibility means accessibility for the author. With that being said do they call semantics a good idea instead of semantics?

You guys need to understand that the author - needs to be able to access things as well as the user. The user does not see the naming conventions or anything under the hood. My topic of convo. is right on target. I left out a million examples because everything I talked about is explained for you as the reader to understand.

I am not incorrect in my naming convention of this thread!

[cooper.semantics]

Be that as it may, I think you've captured some important points there, Cooper.

The importance of #3 may not be as great these days, now that we've got Dragonfly and Firefox, but it's definitely helpful.

Thank you Tommy!

[r937]

With that being said do they call semantics a good idea instead of semantics?

huh?

[cooper.semantics]

huh?

Semantics - is the study of meaning in communication.
Good idea - is the study of meaning in communication. (incorrect)

Do you understand what I am saying?

I do think that the phrase 'good idea' or 'best practices' are too generic to label such a unique topic.

[Karpie]

Author Accessibility means accessibility for the author.

But in your first post you gave a definition of web accessibility that meant something rather different.

I'm not picking on you or trying to start a fight, I just think the choice of words wasn't an accurate one and it would seem I'm not alone in that opinion.

That being said, I'd still like to see some examples of how you think things like #3 could be applied.

[cooper.semantics]

But in your first post you gave a definition of web accessibility that meant something rather different.

I'm not picking on you or trying to start a fight, I just think the choice of words wasn't an accurate one and it would seem I'm not alone in that opinion.

That being said, I'd still like to see some examples of how you think things like #3 could be applied.

No offense taken at all

I was merely using web accessibility to lay down a foundation before bringing up my relevant point which was 'author accessibility'. Some people reading this thread might not fully have an understanding of what this key term is.

[cooper.semantics]

#3. Commenting code blocks, setting a site map for say, commenting certain functionality, notes for back-end developers and etc.

<div id="primary-content">
.....
</div>
<!-- /#primary-content -->

<div id="site-info">
<p>....</p>
</div>
<!-- /#site-info -->

<!-- Toggle Controller -->
<a id="site-statistics" href="#">Site Statistics</a>

<!-- Toggle id="tabular-statistics" -->
<table id="tabular-statistics" summary="....." cellspacing="0">
........
</table>

<!--
Please do not edit anything within 'secondary-nav' because functionality is tied to the specific id's
-->