E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Jennifer Sutton
Date: Tue, Sep 13 2016 4:33PM
Subject: holding software vendors accountable for accessibility
No previous message | Next message →

Brooks and all:


I'm taking the liberty of changing your subject line to one that might
catch people's attention and will certainly be more searchable in the
archives.


I'll also be bcc-ing some folks I know who work on browsers on this
message, including the link to the previous thread, though as we all
know, filing bugs gets much more attention than email ever does. For the
record, the link to the previous thread is this:


In-page Links and Programmatic Focus

http://webaim.org/discussion/mail_thread?threadv88



While I very much understand your frustration, Brooks, I've been around
the comments process for these things, i.e. the ADA regs., for many
years (since the beginning, in fact). I'm not at all concerned by the
relatively small number of comments you note, so far. People tend to
take a while to prepare these things, especially if they are commenting
on behalf of organizations/companies where several people may need to
review and approve. When I worked with folks to file comments, in the
early '90s, we never filed before the last day or two.


That being said, your reminder to submit comments is, I imagine, a
welcome one to those of us in the United States who needed one (like me).


I hope you will keep in mind that most folks on this list are not
representatives of software vendors; most of us are "on your side,"
(including, I expect, the software vendor reps. who are here). So maybe
it would be productive if we brainstormed here about specific
campaigns/collaborations. Typically, beating companies over the heads
with law doesn't make them very cooperative/happy, at least in my
experience, but proposing solutions where vendors are able to see and
take action sure as heck can.


Note that there are many people in the higher ed. arena who are working
with software vendors, either collaboratively, or as individual
entities, but many folks on this list might not know that.


Perhaps folks on this list have missed this post and may take heart from
it, or maybe it was posted, and I missed it:


Why Can't We Make It Easier To Be Accessible - Rosenfeld Media

http://rosenfeldmedia.com/announcements/cant-make-easier-accessible/


I want to stress that this issue of software accessibility reaches far
beyond Microsoft and Adobe, and it is going to be a very big ship to
turn. Will a change in U.S. regulations, if that happens, be enough to
impact this international issue? Time will tell.


In my experience, strategic, steady, and tactfully reasoned efforts win
the game.


So, who wants to propose some constructive next steps to reach out to
software companies -- browser vendors and others -- where they are
(which is typically not on this list, with thanks to those companies who
are here)?


What do software vendors who are here have to say? How can we help you
make change happen?


It seems to me that we've been talking about these kinds of software
issues on this list for well over a decade, now; what can we do that's
new and different? That is assuming that this list is an appropriate
place to coordinate advocacy efforts.


Filing comments is certainly one thing that those of us in the U.S. can
do, but that effort will take a good while to have an impact, so what else?


Best,

Jennifer




On 9/13/2016 2:41 PM, Brooks Newton wrote:
> If browser manufacturers are left out of the culpability loop for ensuring digital accessibility, we can expect to see sporadic support of accessible user experiences as the norm moving forward. Why on earth would these organizations give up one red cent of profit or one hour of "feature building" to develop and test for accessibility if they aren't compelled by law to do so? I am being facetious here, because I can in fact think of many good reasons, other than direct profit potential, to back standardized accessibility support on the part of user agents and other necessary software.
>
> I'd like to ask why software manufacturers have been very specifically excused from being obligated to support standard accessible interaction patterns via regulations, such as the case with the ADA do-over (Title II SANPRM). Who in this close-knit community of ours is giving the DOJ or other regulators the idea that site owners are the only ones who should have legal obligations to support Web accessibility and what is your rationale?
>
> If anyone is interested in reading more along these lines, I encourage you to read my formal response to the latest ADA SANPRM, and to file your own responses to the landmark ruling that will be coming down the pike as a result of this proposed rule making.
>
> Here is a PDF version of my extended remarks about the absurdity of not holding software manufacturers accountable for upholding their end of the digital accessibility equation.
>
> https://www.regulations.gov/contentStreamer?documentId=DOJ-CRT-2016-0009-0052&attachmentNumber=2&disposition=attachment&contentType=pdf
>
> Here is the link to comment on the proposed regulation of Web accessibility for U.S. state and local entities. The comment deadline has been extended until October 7, 2016.
>
> https://www.regulations.gov/comment?D=DOJ-CRT-2016-0009-0047
>
> It looks to me like there have been a grand total of 58 responses submitted and posted to date in regard to this critically important pending regulation. Are people afraid to post personal responses for fear of retribution by their employers? What gives? I know there are at least a hundred passionate followers of this discussion list who have relevant perspectives to share with the Department of Justice on the future of Web accessibility in America.
>
> Brooks Newton
>
>
>

From: Steve Faulkner
Date: Wed, Sep 14 2016 2:01AM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

Brook appears to point to browser vendors as the issue, in my experience
browser vendors are the bright light in accessibility implementation on the
web, they provide an open process for filing bugs and implement standards.
It is mostly the Assistive tech vendors that are a problem as they do not
generally have an open development process and do not participate in the
development of standards.

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 13 September 2016 at 23:33, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:

> Brooks and all:
>
>
> I'm taking the liberty of changing your subject line to one that might
> catch people's attention and will certainly be more searchable in the
> archives.
>
>
> I'll also be bcc-ing some folks I know who work on browsers on this
> message, including the link to the previous thread, though as we all know,
> filing bugs gets much more attention than email ever does. For the record,
> the link to the previous thread is this:
>
>
> In-page Links and Programmatic Focus
>
> http://webaim.org/discussion/mail_thread?threadv88
>
>
>
> While I very much understand your frustration, Brooks, I've been around
> the comments process for these things, i.e. the ADA regs., for many years
> (since the beginning, in fact). I'm not at all concerned by the relatively
> small number of comments you note, so far. People tend to take a while to
> prepare these things, especially if they are commenting on behalf of
> organizations/companies where several people may need to review and
> approve. When I worked with folks to file comments, in the early '90s, we
> never filed before the last day or two.
>
>
> That being said, your reminder to submit comments is, I imagine, a welcome
> one to those of us in the United States who needed one (like me).
>
>
> I hope you will keep in mind that most folks on this list are not
> representatives of software vendors; most of us are "on your side,"
> (including, I expect, the software vendor reps. who are here). So maybe it
> would be productive if we brainstormed here about specific
> campaigns/collaborations. Typically, beating companies over the heads with
> law doesn't make them very cooperative/happy, at least in my experience,
> but proposing solutions where vendors are able to see and take action sure
> as heck can.
>
>
> Note that there are many people in the higher ed. arena who are working
> with software vendors, either collaboratively, or as individual entities,
> but many folks on this list might not know that.
>
>
> Perhaps folks on this list have missed this post and may take heart from
> it, or maybe it was posted, and I missed it:
>
>
> Why Can't We Make It Easier To Be Accessible - Rosenfeld Media
>
> http://rosenfeldmedia.com/announcements/cant-make-easier-accessible/
>
>
> I want to stress that this issue of software accessibility reaches far
> beyond Microsoft and Adobe, and it is going to be a very big ship to turn.
> Will a change in U.S. regulations, if that happens, be enough to impact
> this international issue? Time will tell.
>
>
> In my experience, strategic, steady, and tactfully reasoned efforts win
> the game.
>
>
> So, who wants to propose some constructive next steps to reach out to
> software companies -- browser vendors and others -- where they are (which
> is typically not on this list, with thanks to those companies who are here)?
>
>
> What do software vendors who are here have to say? How can we help you
> make change happen?
>
>
> It seems to me that we've been talking about these kinds of software
> issues on this list for well over a decade, now; what can we do that's new
> and different? That is assuming that this list is an appropriate place to
> coordinate advocacy efforts.
>
>
> Filing comments is certainly one thing that those of us in the U.S. can
> do, but that effort will take a good while to have an impact, so what else?
>
>
> Best,
>
> Jennifer
>
>
>
>
> On 9/13/2016 2:41 PM, Brooks Newton wrote:
>
>> If browser manufacturers are left out of the culpability loop for
>> ensuring digital accessibility, we can expect to see sporadic support of
>> accessible user experiences as the norm moving forward. Why on earth would
>> these organizations give up one red cent of profit or one hour of "feature
>> building" to develop and test for accessibility if they aren't compelled by
>> law to do so? I am being facetious here, because I can in fact think of
>> many good reasons, other than direct profit potential, to back
>> standardized accessibility support on the part of user agents and other
>> necessary software.
>>
>> I'd like to ask why software manufacturers have been very specifically
>> excused from being obligated to support standard accessible interaction
>> patterns via regulations, such as the case with the ADA do-over (Title II
>> SANPRM). Who in this close-knit community of ours is giving the DOJ or
>> other regulators the idea that site owners are the only ones who should
>> have legal obligations to support Web accessibility and what is your
>> rationale?
>>
>> If anyone is interested in reading more along these lines, I encourage
>> you to read my formal response to the latest ADA SANPRM, and to file your
>> own responses to the landmark ruling that will be coming down the pike as a
>> result of this proposed rule making.
>>
>> Here is a PDF version of my extended remarks about the absurdity of not
>> holding software manufacturers accountable for upholding their end of the
>> digital accessibility equation.
>>
>> https://www.regulations.gov/contentStreamer?documentId=DOJ-
>> CRT-2016-0009-0052&attachmentNumber=2&disposition>> attachment&contentType=pdf
>>
>> Here is the link to comment on the proposed regulation of Web
>> accessibility for U.S. state and local entities. The comment deadline has
>> been extended until October 7, 2016.
>>
>> https://www.regulations.gov/comment?D=DOJ-CRT-2016-0009-0047
>>
>> It looks to me like there have been a grand total of 58 responses
>> submitted and posted to date in regard to this critically important pending
>> regulation. Are people afraid to post personal responses for fear of
>> retribution by their employers? What gives? I know there are at least a
>> hundred passionate followers of this discussion list who have relevant
>> perspectives to share with the Department of Justice on the future of Web
>> accessibility in America.
>>
>> Brooks Newton
>>
>>
>>
>>
> > > > >

From: Patrick H. Lauke
Date: Wed, Sep 14 2016 2:25AM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

And to specifically address the issue with how inconsistently/badly
browsers have handled the "keyboard focus should move when following an
in-page link", the crux of the problem was that nothing had ever been
officially specified in any specification, and browsers had to make up
their own interpretation of what should happen.

Finally, the correct/expected behavior has now been properly documented
https://www.w3.org/TR/html51/editing.html#sec-sequential-focus-navigation
(thanks to the hard work of people working on specs, including browser
vendors), so browsers have a well-documented behavior that they can
consistently implement (see for instance the recent change in Chrome's
behavior
https://developers.google.com/web/updates/2016/03/focus-start-point?hl=en).

P

On 14/09/2016 09:01, Steve Faulkner wrote:
> Brook appears to point to browser vendors as the issue, in my experience
> browser vendors are the bright light in accessibility implementation on the
> web, they provide an open process for filing bugs and implement standards.
> It is mostly the Assistive tech vendors that are a problem as they do not
> generally have an open development process and do not participate in the
> development of standards.
>
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
> On 13 September 2016 at 23:33, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Brooks and all:
>>
>>
>> I'm taking the liberty of changing your subject line to one that might
>> catch people's attention and will certainly be more searchable in the
>> archives.
>>
>>
>> I'll also be bcc-ing some folks I know who work on browsers on this
>> message, including the link to the previous thread, though as we all know,
>> filing bugs gets much more attention than email ever does. For the record,
>> the link to the previous thread is this:
>>
>>
>> In-page Links and Programmatic Focus
>>
>> http://webaim.org/discussion/mail_thread?threadv88
>>
>>
>>
>> While I very much understand your frustration, Brooks, I've been around
>> the comments process for these things, i.e. the ADA regs., for many years
>> (since the beginning, in fact). I'm not at all concerned by the relatively
>> small number of comments you note, so far. People tend to take a while to
>> prepare these things, especially if they are commenting on behalf of
>> organizations/companies where several people may need to review and
>> approve. When I worked with folks to file comments, in the early '90s, we
>> never filed before the last day or two.
>>
>>
>> That being said, your reminder to submit comments is, I imagine, a welcome
>> one to those of us in the United States who needed one (like me).
>>
>>
>> I hope you will keep in mind that most folks on this list are not
>> representatives of software vendors; most of us are "on your side,"
>> (including, I expect, the software vendor reps. who are here). So maybe it
>> would be productive if we brainstormed here about specific
>> campaigns/collaborations. Typically, beating companies over the heads with
>> law doesn't make them very cooperative/happy, at least in my experience,
>> but proposing solutions where vendors are able to see and take action sure
>> as heck can.
>>
>>
>> Note that there are many people in the higher ed. arena who are working
>> with software vendors, either collaboratively, or as individual entities,
>> but many folks on this list might not know that.
>>
>>
>> Perhaps folks on this list have missed this post and may take heart from
>> it, or maybe it was posted, and I missed it:
>>
>>
>> Why Can't We Make It Easier To Be Accessible - Rosenfeld Media
>>
>> http://rosenfeldmedia.com/announcements/cant-make-easier-accessible/
>>
>>
>> I want to stress that this issue of software accessibility reaches far
>> beyond Microsoft and Adobe, and it is going to be a very big ship to turn.
>> Will a change in U.S. regulations, if that happens, be enough to impact
>> this international issue? Time will tell.
>>
>>
>> In my experience, strategic, steady, and tactfully reasoned efforts win
>> the game.
>>
>>
>> So, who wants to propose some constructive next steps to reach out to
>> software companies -- browser vendors and others -- where they are (which
>> is typically not on this list, with thanks to those companies who are here)?
>>
>>
>> What do software vendors who are here have to say? How can we help you
>> make change happen?
>>
>>
>> It seems to me that we've been talking about these kinds of software
>> issues on this list for well over a decade, now; what can we do that's new
>> and different? That is assuming that this list is an appropriate place to
>> coordinate advocacy efforts.
>>
>>
>> Filing comments is certainly one thing that those of us in the U.S. can
>> do, but that effort will take a good while to have an impact, so what else?
>>
>>
>> Best,
>>
>> Jennifer
>>
>>
>>
>>
>> On 9/13/2016 2:41 PM, Brooks Newton wrote:
>>
>>> If browser manufacturers are left out of the culpability loop for
>>> ensuring digital accessibility, we can expect to see sporadic support of
>>> accessible user experiences as the norm moving forward. Why on earth would
>>> these organizations give up one red cent of profit or one hour of "feature
>>> building" to develop and test for accessibility if they aren't compelled by
>>> law to do so? I am being facetious here, because I can in fact think of
>>> many good reasons, other than direct profit potential, to back
>>> standardized accessibility support on the part of user agents and other
>>> necessary software.
>>>
>>> I'd like to ask why software manufacturers have been very specifically
>>> excused from being obligated to support standard accessible interaction
>>> patterns via regulations, such as the case with the ADA do-over (Title II
>>> SANPRM). Who in this close-knit community of ours is giving the DOJ or
>>> other regulators the idea that site owners are the only ones who should
>>> have legal obligations to support Web accessibility and what is your
>>> rationale?
>>>
>>> If anyone is interested in reading more along these lines, I encourage
>>> you to read my formal response to the latest ADA SANPRM, and to file your
>>> own responses to the landmark ruling that will be coming down the pike as a
>>> result of this proposed rule making.
>>>
>>> Here is a PDF version of my extended remarks about the absurdity of not
>>> holding software manufacturers accountable for upholding their end of the
>>> digital accessibility equation.
>>>
>>> https://www.regulations.gov/contentStreamer?documentId=DOJ-
>>> CRT-2016-0009-0052&attachmentNumber=2&disposition>>> attachment&contentType=pdf
>>>
>>> Here is the link to comment on the proposed regulation of Web
>>> accessibility for U.S. state and local entities. The comment deadline has
>>> been extended until October 7, 2016.
>>>
>>> https://www.regulations.gov/comment?D=DOJ-CRT-2016-0009-0047
>>>
>>> It looks to me like there have been a grand total of 58 responses
>>> submitted and posted to date in regard to this critically important pending
>>> regulation. Are people afraid to post personal responses for fear of
>>> retribution by their employers? What gives? I know there are at least a
>>> hundred passionate followers of this discussion list who have relevant
>>> perspectives to share with the Department of Justice on the future of Web
>>> accessibility in America.
>>>
>>> Brooks Newton
>>>
>>>
>>>
>>>
>> >> >> >> >>
> > > > >


--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jennifer Sutton
Date: Wed, Sep 14 2016 8:26AM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

All:


Steve and Patrick, thank you for bringing focus back to the very
specific moment, today, for browsers and AT vendors. It was my goal to
take the historic long view, here, based on my recollections of Brooks'
previous comments of software vendors, more generally. We have had these
same discussions more times than I can count (beyyond browsers and AT),
so I was hoping to work for new kinds of change.


But since WebAIM seems to be down for me, such that I can't confirm my
recollection by searching the archives to offer citations, I guess what
you two have said is all that need be said, unless others are interested
in discussing the general subject further.


Good luck to everyone in making the change we wish to see, wherever and
however we can.


Jennifer



On 9/14/2016 1:25 AM, Patrick H. Lauke wrote:
> And to specifically address the issue with how inconsistently/badly
> browsers have handled the "keyboard focus should move when following
> an in-page link", the crux of the problem was that nothing had ever
> been officially specified in any specification, and browsers had to
> make up their own interpretation of what should happen.
>
> Finally, the correct/expected behavior has now been properly
> documented
> https://www.w3.org/TR/html51/editing.html#sec-sequential-focus-navigation
> (thanks to the hard work of people working on specs, including browser
> vendors), so browsers have a well-documented behavior that they can
> consistently implement (see for instance the recent change in Chrome's
> behavior
> https://developers.google.com/web/updates/2016/03/focus-start-point?hl=en).
>
> P
>
> On 14/09/2016 09:01, Steve Faulkner wrote:
>> Brook appears to point to browser vendors as the issue, in my experience
>> browser vendors are the bright light in accessibility implementation
>> on the
>> web, they provide an open process for filing bugs and implement
>> standards.
>> It is mostly the Assistive tech vendors that are a problem as they do
>> not
>> generally have an open development process and do not participate in the
>> development of standards.
>>
>> --
>>
>> Regards
>>
>> SteveF
>> Current Standards Work @W3C
>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>>
>>

From: Brooks Newton
Date: Wed, Sep 14 2016 1:00PM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

Hi Jennifer,

Thanks for changing the subject line of my post. My apology for that screw up.

If you have taken the time to read my SANPRM comment, which I assume you have Jennifer and Steve, you'll notice that I included all software manufacturers that have an impact on the Web browsing experience as ones who should be regulated, in addition to site owners.

For those who haven't read my response (which, by the way was translated to PDF stamped "Accessible" beyond my control), it is available here:

https://www.regulations.gov/contentStreamer?documentId=DOJ-CRT-2016-0009-0052&attachmentNumber=2&disposition=attachment&contentType=pdf

In my DOJ response, I also provided some positive next steps that we as an industry can take now to bring about a more accessible Web experience for folks who browse with one or more disabilities. Patrick is right on point with the idea that we must first develop software standards, before we can hold software to account under the law.

I'm not interested complaining without offering a positive path forward. Make no mistake about it, I'm in awe of the phenomenal groundwork that has been laid by our colleagues to set the stage for inclusion of software regulation in laws such as the ADA. However, I think it is a really bad idea, in my opinion, to craft landmark accessibility legislation without providing for the opportunity for all relevant facets of the Web user experience to be synchronized, harmonized and planned for success.

I have to tell you, that I'm more than just a little bit bothered by the notion that we have discussed the shortcomings of software accessibility support as you say "more times than I can count," yet we still get handed a proposed Web accessibility regulation that goes out of its way to specifically exclude software from the scope of those obligated under the law. Have we discussed this so much that it doesn't even need to be mentioned anymore? Frankly, I think it is just the opposite.

Sometimes I feel like this discussion list serves an echo chamber to ratify and make quasi-official the ideas of a limited number of experts who do not necessarily consider the whole accessibility ecosystem in their recommended approaches to digital accessibility. Tightly focused "small picture" work is mission-critical for making progress on especially difficult technical challenges. But I think too often we get mired in the "very specific moment" as we search for answers to technical problems the lie before us. I promise you that I have read the discussions in this forum as thoroughly as you have, and I truly want for there to be more enhanced discussion of big picture issues. It is almost like there is an assumption that we've figured out the right direction in the journey, so now it's just time to keep our heads down in code without time to look up to see if we are headed off of a cliff in our journey. I guarantee you that if we pass the Title II update to the ADA without the inclusion of software regulation, we'll go right off that cliff with our heads buried in the minutiae all the way to the bottom.

How can we possibly hope for widespread adoption of accessible digital content without coordinating site owner responsibilities with software responsibilities? Are you thinking of new kinds of change that still put the full legal burden on site owners, without also holding responsible OS/UA/AT manufacturers? If so, please explain how you think that will work?

Brooks Newton

> On Sep 14, 2016, at 9:26 AM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>
> All:
>
>
> Steve and Patrick, thank you for bringing focus back to the very specific moment, today, for browsers and AT vendors. It was my goal to take the historic long view, here, based on my recollections of Brooks' previous comments of software vendors, more generally. We have had these same discussions more times than I can count (beyyond browsers and AT), so I was hoping to work for new kinds of change.
>
>
> But since WebAIM seems to be down for me, such that I can't confirm my recollection by searching the archives to offer citations, I guess what you two have said is all that need be said, unless others are interested in discussing the general subject further.
>
>
> Good luck to everyone in making the change we wish to see, wherever and however we can.
>
>
> Jennifer
>
>
>
>> On 9/14/2016 1:25 AM, Patrick H. Lauke wrote:
>> And to specifically address the issue with how inconsistently/badly browsers have handled the "keyboard focus should move when following an in-page link", the crux of the problem was that nothing had ever been officially specified in any specification, and browsers had to make up their own interpretation of what should happen.
>>
>> Finally, the correct/expected behavior has now been properly documented https://www.w3.org/TR/html51/editing.html#sec-sequential-focus-navigation (thanks to the hard work of people working on specs, including browser vendors), so browsers have a well-documented behavior that they can consistently implement (see for instance the recent change in Chrome's behavior https://developers.google.com/web/updates/2016/03/focus-start-point?hl=en).
>>
>> P
>>
>>> On 14/09/2016 09:01, Steve Faulkner wrote:
>>> Brook appears to point to browser vendors as the issue, in my experience
>>> browser vendors are the bright light in accessibility implementation on the
>>> web, they provide an open process for filing bugs and implement standards.
>>> It is mostly the Assistive tech vendors that are a problem as they do not
>>> generally have an open development process and do not participate in the
>>> development of standards.
>>>
>>> --
>>>
>>> Regards
>>>
>>> SteveF
>>> Current Standards Work @W3C
>>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>
>

From: Chagnon | PubCom
Date: Wed, Sep 14 2016 2:43PM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

Agree with Brooks.
One of the key problems with the SANPRM (and all other regulations regarding accessibility) is that it doesn't address the entire scope of how electronic information is created, published, and presented to the user.

Doesn't matter whether it's HTML or a PDF on a website, the problem is the same; the end product isn't necessarily fully accessible and sometimes it's the software that's missing the grade, not our content.

There are 5 stakeholders in accessibility:

1. The assistive technologies, browsers, and their manufacturers. Are they developing tools that keep up with the WCAG and PDF/UA standards?

2. Us, the content creators. Are we making our materials per the WCAG and PDF/UA standards?

3. The standards themselves. They are difficult and confusing to understand (I type this as I'm closing up my classroom from teaching accessibility for 3 days). Can they be simplified and still make our work accessible? Can they be written and presented to mere mortals (the content creators, not programmers) in a way that they can understand them and use them?

4. The software manufacturers. Here, I mean the software we content creators use to create content, namely: Microsoft Word and PowerPoint, Adobe InDesign, and Adobe Acrobat. 18 years after Sec. 508 was passed, and MS Word still can't output a compliant PDF. Nor can Adobe InDesign. And Acrobat? Don't get me started. And do we have an HTML authoring tools that help us make accessible websites?

5. The end users. Do they have the latest version of their assistive technology? Have they taken training in how to use it or read the manual?

I get the sense that DOJ doesn't really know the extent of the problem, so I'm glad Books and others have filed their comments. Don't leave out the AT manufacturers, nor Adobe or Microsoft. They are critical links in the entire accessibility workflow and should be cited in the proposed regulation.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers
for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
— — —

From: Don Mauck
Date: Wed, Sep 14 2016 2:52PM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

Well written!!

-----Original Message-----
From: Chagnon | PubCom [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, September 14, 2016 2:44 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Agree with Brooks.
One of the key problems with the SANPRM (and all other regulations regarding accessibility) is that it doesn't address the entire scope of how electronic information is created, published, and presented to the user.

Doesn't matter whether it's HTML or a PDF on a website, the problem is the same; the end product isn't necessarily fully accessible and sometimes it's the software that's missing the grade, not our content.

There are 5 stakeholders in accessibility:

1. The assistive technologies, browsers, and their manufacturers. Are they developing tools that keep up with the WCAG and PDF/UA standards?

2. Us, the content creators. Are we making our materials per the WCAG and PDF/UA standards?

3. The standards themselves. They are difficult and confusing to understand (I type this as I'm closing up my classroom from teaching accessibility for 3 days). Can they be simplified and still make our work accessible? Can they be written and presented to mere mortals (the content creators, not programmers) in a way that they can understand them and use them?

4. The software manufacturers. Here, I mean the software we content creators use to create content, namely: Microsoft Word and PowerPoint, Adobe InDesign, and Adobe Acrobat. 18 years after Sec. 508 was passed, and MS Word still can't output a compliant PDF. Nor can Adobe InDesign. And Acrobat? Don't get me started. And do we have an HTML authoring tools that help us make accessible websites?

5. The end users. Do they have the latest version of their assistive technology? Have they taken training in how to use it or read the manual?

I get the sense that DOJ doesn't really know the extent of the problem, so I'm glad Books and others have filed their comments. Don't leave out the AT manufacturers, nor Adobe or Microsoft. They are critical links in the entire accessibility workflow and should be cited in the proposed regulation.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
— — —

From: Jennifer Sutton
Date: Wed, Sep 14 2016 3:03PM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

Perhaps there was some doubt as to whether I agreed with Brooks. I'll
set the record straight by saying that I certainly do.

I'm glad that a focus on today's specifics, at a micro-level, seems to
generally work great for folks on the list. To that end, I'll be sure to
take my big-picture hopes and efforts, along with my advocacy, into
places where I feel I make a difference, rather than cluttering the list
with them.

Good luck, everyone, as we journey together to make a more accessible
world, involving all of the stakeholders who must be a part of the
change and solutions I believe we wish to see.

For my part, I'm off to write my DoJ comments. Won't you join me?

Best,
Jennifer

From: Jamous, JP
Date: Wed, Sep 14 2016 3:07PM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

FYI, I second this whole thread. What we need is action. We need to enforce the fact that JAWS stands for Job Access with Speech. If they cannot live up to that title, then they should rename it.

I use Visual Studio to program web sites and other types of apps. As Visual Studio 2015 came out, there was a smiley face icon in the help menu. I noticed that the log-in form was totally inaccessible for me to make Visual Studio 2015 Community fully licensed as my counterparts.

I sent a sad face and explained the issue to Microsoft. As they deployed service pack 5, the issue was fixed. So yes, one person can make a difference and multiple ones can make a bigger difference.

We need to team up and submit our issues to those venders starting with the AT ones.

I already have various JAWS bugs that have been tested and logged. I also have ones for VoiceOver 9.3.5 and I need a group of people to email the venders after I file the issues to enforce the change.

FYI, do not upgrade to iOS 10 as VoiceOver is not reading any aria attributes. That's a prime example of their failures.




**************************************************

Jean-Pierre Jamous
Digital Accessibility Specialist & Developer
UI Accessibility Team

SME for EBN Include
Digital Accessibility Specialist & Blind and Visually Impaired Expert

The only limitations in life are those we set for ourselves

**************************************************















-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Wednesday, September 14, 2016 3:53 PM
To: = EMAIL ADDRESS REMOVED = ; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Well written!!

-----Original Message-----
From: Chagnon | PubCom [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, September 14, 2016 2:44 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Agree with Brooks.
One of the key problems with the SANPRM (and all other regulations regarding accessibility) is that it doesn't address the entire scope of how electronic information is created, published, and presented to the user.

Doesn't matter whether it's HTML or a PDF on a website, the problem is the same; the end product isn't necessarily fully accessible and sometimes it's the software that's missing the grade, not our content.

There are 5 stakeholders in accessibility:

1. The assistive technologies, browsers, and their manufacturers. Are they developing tools that keep up with the WCAG and PDF/UA standards?

2. Us, the content creators. Are we making our materials per the WCAG and PDF/UA standards?

3. The standards themselves. They are difficult and confusing to understand (I type this as I'm closing up my classroom from teaching accessibility for 3 days). Can they be simplified and still make our work accessible? Can they be written and presented to mere mortals (the content creators, not programmers) in a way that they can understand them and use them?

4. The software manufacturers. Here, I mean the software we content creators use to create content, namely: Microsoft Word and PowerPoint, Adobe InDesign, and Adobe Acrobat. 18 years after Sec. 508 was passed, and MS Word still can't output a compliant PDF. Nor can Adobe InDesign. And Acrobat? Don't get me started. And do we have an HTML authoring tools that help us make accessible websites?

5. The end users. Do they have the latest version of their assistive technology? Have they taken training in how to use it or read the manual?

I get the sense that DOJ doesn't really know the extent of the problem, so I'm glad Books and others have filed their comments. Don't leave out the AT manufacturers, nor Adobe or Microsoft. They are critical links in the entire accessibility workflow and should be cited in the proposed regulation.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
— — —

From: Jim Homme
Date: Wed, Sep 14 2016 5:17PM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

Hi,
Keeping this bug in mind, where is there documentation on rolling back and its iimplications?

Thanks.

Jim


=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jamous, JP
Sent: Wednesday, September 14, 2016 5:07 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

FYI, I second this whole thread. What we need is action. We need to enforce the fact that JAWS stands for Job Access with Speech. If they cannot live up to that title, then they should rename it.

I use Visual Studio to program web sites and other types of apps. As Visual Studio 2015 came out, there was a smiley face icon in the help menu. I noticed that the log-in form was totally inaccessible for me to make Visual Studio 2015 Community fully licensed as my counterparts.

I sent a sad face and explained the issue to Microsoft. As they deployed service pack 5, the issue was fixed. So yes, one person can make a difference and multiple ones can make a bigger difference.

We need to team up and submit our issues to those venders starting with the AT ones.

I already have various JAWS bugs that have been tested and logged. I also have ones for VoiceOver 9.3.5 and I need a group of people to email the venders after I file the issues to enforce the change.

FYI, do not upgrade to iOS 10 as VoiceOver is not reading any aria attributes. That's a prime example of their failures.




**************************************************

Jean-Pierre Jamous
Digital Accessibility Specialist & Developer UI Accessibility Team

SME for EBN Include
Digital Accessibility Specialist & Blind and Visually Impaired Expert

The only limitations in life are those we set for ourselves

**************************************************















-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Wednesday, September 14, 2016 3:53 PM
To: = EMAIL ADDRESS REMOVED = ; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Well written!!

-----Original Message-----
From: Chagnon | PubCom [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, September 14, 2016 2:44 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Agree with Brooks.
One of the key problems with the SANPRM (and all other regulations regarding accessibility) is that it doesn't address the entire scope of how electronic information is created, published, and presented to the user.

Doesn't matter whether it's HTML or a PDF on a website, the problem is the same; the end product isn't necessarily fully accessible and sometimes it's the software that's missing the grade, not our content.

There are 5 stakeholders in accessibility:

1. The assistive technologies, browsers, and their manufacturers. Are they developing tools that keep up with the WCAG and PDF/UA standards?

2. Us, the content creators. Are we making our materials per the WCAG and PDF/UA standards?

3. The standards themselves. They are difficult and confusing to understand (I type this as I'm closing up my classroom from teaching accessibility for 3 days). Can they be simplified and still make our work accessible? Can they be written and presented to mere mortals (the content creators, not programmers) in a way that they can understand them and use them?

4. The software manufacturers. Here, I mean the software we content creators use to create content, namely: Microsoft Word and PowerPoint, Adobe InDesign, and Adobe Acrobat. 18 years after Sec. 508 was passed, and MS Word still can't output a compliant PDF. Nor can Adobe InDesign. And Acrobat? Don't get me started. And do we have an HTML authoring tools that help us make accessible websites?

5. The end users. Do they have the latest version of their assistive technology? Have they taken training in how to use it or read the manual?

I get the sense that DOJ doesn't really know the extent of the problem, so I'm glad Books and others have filed their comments. Don't leave out the AT manufacturers, nor Adobe or Microsoft. They are critical links in the entire accessibility workflow and should be cited in the proposed regulation.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
— — —

From: Jamous, JP
Date: Thu, Sep 15 2016 5:59AM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | Next message →

Sorry Jim. I am not following you. Can you word your question differently?

Which bug and what rollout?




**************************************************

Jean-Pierre Jamous
Digital Accessibility Specialist & Developer
UI Accessibility Team

SME for EBN Include
Digital Accessibility Specialist & Blind and Visually Impaired Expert

The only limitations in life are those we set for ourselves

**************************************************














-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Homme
Sent: Wednesday, September 14, 2016 6:18 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Hi,
Keeping this bug in mind, where is there documentation on rolling back and its iimplications?

Thanks.

Jim


=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jamous, JP
Sent: Wednesday, September 14, 2016 5:07 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

FYI, I second this whole thread. What we need is action. We need to enforce the fact that JAWS stands for Job Access with Speech. If they cannot live up to that title, then they should rename it.

I use Visual Studio to program web sites and other types of apps. As Visual Studio 2015 came out, there was a smiley face icon in the help menu. I noticed that the log-in form was totally inaccessible for me to make Visual Studio 2015 Community fully licensed as my counterparts.

I sent a sad face and explained the issue to Microsoft. As they deployed service pack 5, the issue was fixed. So yes, one person can make a difference and multiple ones can make a bigger difference.

We need to team up and submit our issues to those venders starting with the AT ones.

I already have various JAWS bugs that have been tested and logged. I also have ones for VoiceOver 9.3.5 and I need a group of people to email the venders after I file the issues to enforce the change.

FYI, do not upgrade to iOS 10 as VoiceOver is not reading any aria attributes. That's a prime example of their failures.




**************************************************

Jean-Pierre Jamous
Digital Accessibility Specialist & Developer UI Accessibility Team

SME for EBN Include
Digital Accessibility Specialist & Blind and Visually Impaired Expert

The only limitations in life are those we set for ourselves

**************************************************















-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Wednesday, September 14, 2016 3:53 PM
To: = EMAIL ADDRESS REMOVED = ; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Well written!!

-----Original Message-----
From: Chagnon | PubCom [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, September 14, 2016 2:44 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] holding software vendors accountable for accessibility

Agree with Brooks.
One of the key problems with the SANPRM (and all other regulations regarding accessibility) is that it doesn't address the entire scope of how electronic information is created, published, and presented to the user.

Doesn't matter whether it's HTML or a PDF on a website, the problem is the same; the end product isn't necessarily fully accessible and sometimes it's the software that's missing the grade, not our content.

There are 5 stakeholders in accessibility:

1. The assistive technologies, browsers, and their manufacturers. Are they developing tools that keep up with the WCAG and PDF/UA standards?

2. Us, the content creators. Are we making our materials per the WCAG and PDF/UA standards?

3. The standards themselves. They are difficult and confusing to understand (I type this as I'm closing up my classroom from teaching accessibility for 3 days). Can they be simplified and still make our work accessible? Can they be written and presented to mere mortals (the content creators, not programmers) in a way that they can understand them and use them?

4. The software manufacturers. Here, I mean the software we content creators use to create content, namely: Microsoft Word and PowerPoint, Adobe InDesign, and Adobe Acrobat. 18 years after Sec. 508 was passed, and MS Word still can't output a compliant PDF. Nor can Adobe InDesign. And Acrobat? Don't get me started. And do we have an HTML authoring tools that help us make accessible websites?

5. The end users. Do they have the latest version of their assistive technology? Have they taken training in how to use it or read the manual?

I get the sense that DOJ doesn't really know the extent of the problem, so I'm glad Books and others have filed their comments. Don't leave out the AT manufacturers, nor Adobe or Microsoft. They are critical links in the entire accessibility workflow and should be cited in the proposed regulation.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
— — —

From: Birkir R. Gunnarsson
Date: Thu, Sep 15 2016 7:05AM
Subject: Re: holding software vendors accountable for accessibility
← Previous message | No next message

Great thread people, this is so true.
The problem with accessible web content is also its greatest strength,
it is constantly evolving, and we make sure that you don't require a
PHD in rocket science to put your content out on the web, but if that
content is to be made accessible all the players in the chain, from
the software you use to author your content to the assistive
technology that translates it into information most suitable for the
end users does its part and, yes, where is the end user in all this?
I don't know how many times I received complaints from NVDA users when
I used a modal popup dialog and NVDA was stuck in forms mode.
The users just did not know that pressing NVDA-spacebar turned the mode off.
The bug has been sitting with NVDA for years and either has not been
fixed yet, or they think it isn't a bug but a "feature" (note, not
verified for 2016.3).
And NVDA are great, responsive, and do an incredible job (just so
people know Iam not singling them out, they are just an easy target
because they do the right thing and make their bug tracking system
public).
I don't have the answers either, other than just continuing to file
bugs when they are encountered and working on the ARIA Authroing
Practices guide to make ARIA easier to understand and use.
I still think we have come a longway from the days of DHTML and Flash,
let's not forget it, but there is an even longer road ahead.




On 9/15/16, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
> Sorry Jim. I am not following you. Can you word your question differently?
>
> Which bug and what rollout?
>
>
>
>
> **************************************************
>
> Jean-Pierre Jamous
> Digital Accessibility Specialist & Developer
> UI Accessibility Team
>
> SME for EBN Include
> Digital Accessibility Specialist & Blind and Visually Impaired Expert
>
> The only limitations in life are those we set for ourselves
>
> **************************************************
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Homme
> Sent: Wednesday, September 14, 2016 6:18 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] holding software vendors accountable for
> accessibility
>
> Hi,
> Keeping this bug in mind, where is there documentation on rolling back and
> its iimplications?
>
> Thanks.
>
> Jim
>
>
> =========> Jim Homme,
> Accessibility Consultant,
> Bender HighTest Accessibility Team
> Bender Consulting Services, Inc.,
> 412-787-8567,
> = EMAIL ADDRESS REMOVED =
> http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
> E+R=O
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jamous, JP
> Sent: Wednesday, September 14, 2016 5:07 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] holding software vendors accountable for
> accessibility
>
> FYI, I second this whole thread. What we need is action. We need to enforce
> the fact that JAWS stands for Job Access with Speech. If they cannot live up
> to that title, then they should rename it.
>
> I use Visual Studio to program web sites and other types of apps. As Visual
> Studio 2015 came out, there was a smiley face icon in the help menu. I
> noticed that the log-in form was totally inaccessible for me to make Visual
> Studio 2015 Community fully licensed as my counterparts.
>
> I sent a sad face and explained the issue to Microsoft. As they deployed
> service pack 5, the issue was fixed. So yes, one person can make a
> difference and multiple ones can make a bigger difference.
>
> We need to team up and submit our issues to those venders starting with the
> AT ones.
>
> I already have various JAWS bugs that have been tested and logged. I also
> have ones for VoiceOver 9.3.5 and I need a group of people to email the
> venders after I file the issues to enforce the change.
>
> FYI, do not upgrade to iOS 10 as VoiceOver is not reading any aria
> attributes. That's a prime example of their failures.
>
>
>
>
> **************************************************
>
> Jean-Pierre Jamous
> Digital Accessibility Specialist & Developer UI Accessibility Team
>
> SME for EBN Include
> Digital Accessibility Specialist & Blind and Visually Impaired Expert
>
> The only limitations in life are those we set for ourselves
>
> **************************************************
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Don Mauck
> Sent: Wednesday, September 14, 2016 3:53 PM
> To: = EMAIL ADDRESS REMOVED = ; WebAIM Discussion List
> < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] holding software vendors accountable for
> accessibility
>
> Well written!!
>
> -----Original Message-----
> From: Chagnon | PubCom [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, September 14, 2016 2:44 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] holding software vendors accountable for
> accessibility
>
> Agree with Brooks.
> One of the key problems with the SANPRM (and all other regulations regarding
> accessibility) is that it doesn't address the entire scope of how electronic
> information is created, published, and presented to the user.
>
> Doesn't matter whether it's HTML or a PDF on a website, the problem is the
> same; the end product isn't necessarily fully accessible and sometimes it's
> the software that's missing the grade, not our content.
>
> There are 5 stakeholders in accessibility:
>
> 1. The assistive technologies, browsers, and their manufacturers. Are they
> developing tools that keep up with the WCAG and PDF/UA standards?
>
> 2. Us, the content creators. Are we making our materials per the WCAG and
> PDF/UA standards?
>
> 3. The standards themselves. They are difficult and confusing to understand
> (I type this as I'm closing up my classroom from teaching accessibility for
> 3 days). Can they be simplified and still make our work accessible? Can they
> be written and presented to mere mortals (the content creators, not
> programmers) in a way that they can understand them and use them?
>
> 4. The software manufacturers. Here, I mean the software we content
> creators use to create content, namely: Microsoft Word and PowerPoint, Adobe
> InDesign, and Adobe Acrobat. 18 years after Sec. 508 was passed, and MS Word
> still can't output a compliant PDF. Nor can Adobe InDesign. And Acrobat?
> Don't get me started. And do we have an HTML authoring tools that help us
> make accessible websites?
>
> 5. The end users. Do they have the latest version of their assistive
> technology? Have they taken training in how to use it or read the manual?
>
> I get the sense that DOJ doesn't really know the extent of the problem, so
> I'm glad Books and others have filed their comments. Don't leave out the AT
> manufacturers, nor Adobe or Microsoft. They are critical links in the entire
> accessibility workflow and should be cited in the proposed regulation.
>
> --Bevi Chagnon
>
> — — —
> Bevi Chagnon | www.PubCom.com
> Technologists, Consultants, Trainers, Designers, and Developers for
> publishing & communication
> | Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
> — — —
>
> > > http://webaim.org/discussion/archives
> > > > http://webaim.org/discussion/archives
> > > > http://webaim.org/discussion/archives
> > > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.