E-mail List Archives

Search E-mail List Archives for

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

From: Jared Smith
Date: Tue, Sep 13 2005 4:40PM
Subject: Dreamweaver 8 first impressions
No previous message | Next message →

Dreamweaver 8 is now available. I thought I'd put together my first
impressions regarding new accessibility features (or the lack thereof).
This is not meant to be critical of Dreamweaver, which has come a long way
in regards to accessibility, but is intended to be helpful for those of
you who may be interested in how it supports accessibility.

- In very preliminary testing, it appears that the authoring environment
is MUCH more keyboard and screenreader friendly, with expanded shortcut
keys for environment navigation.

- The accessibility options are now enabled by default. The prompts for
forms, frames, media, and images now display by default when you insert
these objects. A dialog displays to allow you to easily disable these
options if you choose to. The burden is now on the developer to disable
them, rather than to somehow discover that they are there and then enable
them.

- In an improvement over MX 2004, the accessibility dialogs now display
when certain elements are added when in Code view, rather than only when
in Design view.

- DW still prompts for and inserts labels for form buttons and image form
elements. These elements should not have and do not need labels.

- DW does not prompt for labels when inserting form elements in code view,
except for when inserting a textarea, in which case it inserts it as
<textarea label="***"> which is invalid HTML.

- The accessibility dialog still prompts for Access key and Tab order for
form elements. Access key and Tab order are also options when you insert
hyperlinks and media objects (why media?). For accessibilities sake, these
things should probably be left to those that understand how to use them
(and those that do, usually don't use them) and not provided as an option
to everyone.

- The table accessibility dialog allows the same accessibility options as
MX 2004 - caption, summary, and headers (using scope) for rows, columns,
or both. There are no additional options for headers and id groupings for
complex/nested table headers.

- If you indicate that your table has both row and column headers,
Dreamweaver will designate the top-left cell as a column header. In some
instances, this cell may actually be a row header or not a header at all.

- You can now add title when inserting hyperlinks, form elements (even
hidden ones!?!), and media objects, but not images.

- The UsableNet accessibility reference appears to be pretty much the same
as in previous versions (errors and all). While a succint and easy to use
reference, it is only listed by RULE type, rather than by element type or
standard (e.g., section 508). This means that if you don't understand what
the rule means, it is not of much use. The ability to search the reference
would be wonderful.

- The accessibility report now includes WCAG priority 2 (as well as
Section 508 and WCAG P1, as in previous versions) . In general, the report
still requires a deep understanding of accessibility in the first place
(in which case, you probably wouldn't be using this reporting mechanism
anyways). While the report lists items as being relevant to Section 508 or
WCAG, it provides no information about what Section 508 or WCAG is. Nor
does it provide links to or descriptions of the actual guidelines.

The report format lists items as FAILED or MANUAL. The list of MANUAL
items is often so long as to quickly make the report overly daunting. Some
reported items are rather extraneous and not very important. 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)

I ran the report on a very simple (100 words and a dozen or so images)
document with 0 accessibility issues and it returned about 300 MANUAL
checks (and a few false FAILED elements too). Perhaps a more user-friendly
reporting method would benefit users who are not already familiar with
accessibility standards and guidelines? Repair features would also be very
welcome in future versions.

- While the direct accessibility features in version 8 have not expanded
much, the authoring environment now supports much easier and better
development of semantically correct, properly structured, CSS driven,
standards compliant Web sites. The CSS support is AMAZING and will greatly
enhance my ability to quickly design pages to accessibility, CSS, and
XHTML standards.


In all, Dreamweaver 8 is a step forward in regards to direct accessibility
support, albeit a baby step - especially when compared with the vast
accessibility improvements introduced in Dreamweaver MX (since which only
minor changes have been made). While it is easy to be critical, I also
realize that I, as a developer, have not volunteered my feedback and
suggestions to the Macromedia development or accessibility team. Perhaps
this feedback (and any others you can provide) will be of use to them, and
to those of you who are using Dreamweaver.

Sorry this is so long. I'll probably comprile this into an article for our
site, but thought it might be of interest to you now.

Jared Smith
WebAIM.org

From: Jukka K. Korpela
Date: Wed, Sep 14 2005 4:40AM
Subject: Re: Dreamweaver 8 first impressions
← Previous message | Next message →

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.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: CFIT
Date: Thu, Sep 15 2005 8:40AM
Subject: Re: Dreamweaver 8 first impressions
← Previous message | Next message →

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 ADDRESS 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.
>

From: Andrew Kirkpatrick
Date: Thu, Sep 15 2005 10:00AM
Subject: RE: Dreamweaver 8 first impressions
← Previous message | No next message

First of all, thanks for the review, Jared. I'll be checking your
issues against bugs we've logged internally.

> 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.

This is a complicated topic, and one that we're interested in your
feedback on. I agree that as a rule, manual checks can to be
overwhelming in any web accessibility evaluation tool, in Dreamweaver or
not. If you are familiar with the manual checks that need to be done and
just want to use the checker as a quick test to make sure that you
aren't missing anything that the tools can find, you can disable all
manual checks which tends to reduce the volume considerably.

> 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?

Contribute will not add semantics when there is none already, but if you
specify headings, links, table headings, tables, lists, etc., Contribute
will create the appropriate HTML elements.

AWK

Andrew Kirkpatrick
Principal Accessibility Engineer, Macromedia
= EMAIL ADDRESS REMOVED =