WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Dreamweaver 8 first impressions

for

From: CFIT
Date: Sep 15, 2005 8:40AM

I attended the launch of the new Macromedia Studio 8 yesterday in
Dublin, Ireland. There are some interesting features/improvements in
Dreamweaver which will enable easier use of CSS for designers as well as
some improvements in the "hand coder" environment, which are welcome.
I'm sure other forums would cover this. After lots of stuff on CSS
driven drop down menus and "workflow" enhancements (which I soon tired
of hearing about), the issue of accessibility was one that was touched
on briefly by the speaker from Macromedia and in a rather surface and
cursory manner. She spoke of elements having "accessibility tags" but
didnt really explain what that meant - and how they were enabled by
default and you could "turn them off" if you wanted to but she wouldn't.
Good stuff so far.

I read the earlier post where Jared mentioned that the accessibility
reports that were generated seemed overly complicated and I have
concerns that this in itself could be counter productive, as developers
who are new to accessibility could very easily just "turn off
accessibility dialogue" if it all got too much for them. And its
feasible that many will. I thought I may be able to discuss this but, no
dice.

One thing that I though was interested was that they have dropped
Freehand from the Studio (now they are being absorbed by Adobe, step up
Illustrator) and included two new(to Studio) programs Contribute and
Flashpaper. I have used neither but I had a couple of questions for the
Macromedia team. You seemed to be able to put content into Contribute
(from MS Word et al) and bounce it into you webpage template and easily
update your website. Fine. But is it structured content? Will Contribute
apply any semantic structure to unformatted content?

Then there was FlashPaper. This app lets you create PDF's and Flash
documents in a flash (sorry). I asked if there was any source structure
applied but she seemed unsure. Looking through the glossy mag they gave
us suggests that source formatting is maintained but it obviously has to
be applied beforehand. Its primarily for print anyway (hence the "Paper"
element) and does look interesting. But I am unsure if it supports
"tags" etc in creating PDF's but I'm sure they could fix that when they
do a "mind meld" with Adobe.

It occurred to me that as in Adobe Reader 7 if a document is not tagged
with XML, it generates its own structure, on the fly, that is "inferred"
by the document/fonts used. I wonder if they will "merge" these
technologies in time and use them as a kind of automated structure tool
for the semantically incorrect??

Anyway, i just though I'd add to the thread.

Joshue O Connor

Web Accessibility Consultant

**Centre for Inclusive Technology (CFIT)* *
National Council for the Blind of Ireland

<EMAIL REMOVED> +353 1 8821915



featurestJukka K. Korpela wrote:

> On Tue, 13 Sep 2005, Jared Smith wrote:
>
>> - DW still prompts for and inserts labels for form buttons and image
>> form elements. These elements should not have and do not need labels.
>
>
> Although most buttons, including image submit buttons, do not need
> labels and should not have labels, and although it's a poor idea to
> prompt for them by default, I have to disagree on the general statement.
>
> An explanation that is closely related to a button is best written as
> a label for it, e.g.
>
> <label for="sub">Subscribe to our weekly newsletter:</label>
> <input id="sub" type="submit" value="Subscribe">
>
> Putting the explanation into the button itself is one possibility, but
> often a poor one. Button texts should be short, concise and verb-like,
> expressing that something will happen if you click on the button.
> But often the button needs an explanation, just like a text input field
> for example.
>
>> - You can now add title when inserting hyperlinks, form elements
>> (even hidden ones!?!), and media objects, but not images.
>
>
> I hidden field with a title attribute sounds odd, but it complies with
> specifications, and in some situations, the attribute could work as
> comment-like documentation and information to a person who reads the
> HTML source. It has nothing to do with accessibility, of course.
>
>> For instance, EVERY image on the page returns warnings for each of
>> the following:
>> * ensuring sufficient contrast
>> * "non spacer IMG with equivalent ALT" (why does the report think
>> that only spacer images should have alt=""?)
>> * "non spacer IMG needs LONGDESC"
>> * "use markup rather than images" (with a description that talks
>> about MathML and stuff)
>
>
> Sounds very bad. It's sufficiently harmful that specifications and
> some tutorials recommend LONGDESC in the first place (it's wasted work
> at best, but it often leads to wrong decisions, like putting essential
> information into LONGDESC _only_), but an unqualified advice "non
> spacer IMG needs LONGDESC" is a really big disservice.
>