PDF versions have just been added to the post. If you scan through to the sections indicated in the post, you'll find the proposed changes marked in red.
The comment period is for the board to get external feedback now that we have specific proposed language in place, even if no new issues are raised.
Here is a good set of instructions for the semantically correct HTML for marking up a revised document to be displayed on the web: Comparing and contrasting ins, del, and s
The post includes some good suggestions for styling the inserted and deleted text that provide better accessibility than browser defaults.
Next time you need to show your users proposed changes, there is no need for links to .doc or .pdf files. Just use good HTML because it is always more accessible.
Thanks for the link! Unfortunately, the problem with presenting documents in HTML has more to do with staff abilities and how they are drafted.
There are many people who volunteer for the OTW whose knowledge of HTML is limited to non-existent, and documents are not drafted this way internally. Rather, most are done with a word processing software that does not allow for automatic coding -- it must all be added manually. For example, when the OTW's annual report is ready for release we are able to create a PDF within a day but it then needs to be sent to our Web Strategy, Design & Development committee for manual coding. The HTML version can then take weeks to be completed depending on the availability of Web's staff. As such we generally only go through this process for finished official documents, especially since there might have to be multiple drafts and thus multiple delays while they are coded.
I was aware that doing this the right way, that is, the way that makes the information accessible to the most users is more work than your quick posting of a link to a document download and then letting the user do the work. Or not be able to read it at all.
It is also painfully obvious that the available people to work on the front end of any of your sites is a count on one hand number.
But thank you for your comment which is the single best illustration I've seen in a while of why accessibility and usability begin in the very foundation of an organization.
Accessibility has to be in the mind of the creators of a site. All of them. It has to be there when you first think up a new feature or a new project. It has to be there when you talk about the professional development of your volunteers and "staffers". Of course, you have to actually promote professional development in the first place. It sure sounds like you're relying on what your volunteers know the day they sign up.
You, the OTW, are stuck on adding on accessibility as a feature later, when you get the time, when all the important things are done first. When it doesn't interfere with the way you've always done it. When someone volunteers who already knows more than how to run up a Livejournal post. I know you're really proud that you've made your sites work (mostly) with screen readers, but that's not accessibility. Clearly, you see accessibility as a barrier to development and as an optional enhancement.
You have chosen to do this. You have made the institutional choice to not provide accessible web services but to pretend you'll totally get to it some day. Is it too late now for you to ever change your attitude?
Comment on Proposed Content Policy ToS and FAQ changes
OTW_Communications (Official) Sat 29 Jun 2013 12:26AM UTC
Comment Actions
Nonny Quixote (Guest) Tue 20 Aug 2013 02:50PM UTC
Comment Actions
OTW_Communications (Official) Wed 21 Aug 2013 01:16AM UTC
Comment Actions
Nonny Quixote (Guest) Wed 21 Aug 2013 01:51PM UTC
Comment Actions